gbadev.org forum archive

I was wondering; everyone saw how the DS displays kinda pixelish graphics.

Now I'm not a very great coder in graphical stuff, so I'm wondering of by any chance later it will be possible to anti-alias stuff. Cause that would sure make things a lot prettier. But will this be possible, and more important, do you think it will slow stuff down too much?

I think the DS already makes quite extensive use of AA. Just look at the current 3D games available. The polygon outlining is surprisingly smooth, even mario (that look curvier then the N64 version) has nice edges.
The screenshot you are showing is....extremely ugly, but then again: it's EA, what did you expect :p. What a DS could use (and I don't understand why nintendo didn't include this) is a form of texture filtering, because the pixelated textures do stand out sometimes.

The DS does seem to use AA, but not very well. I had to look very closely in Mario 64 to see if it is AA'd or not, and I could just barely make out smooth edges. So does the DS use AA? Yes, I'm sure it does. Does it do it well? I'd say 1xAA, it needs 2x.

is 1xAA a limit creatd by N or by the programmers?

I think it's possible to to do a software rendered 2xAA but i'm afraid that really would be a waste of cpu. I don't know much about theese things though..
_________________
http://manifested.ath.cx

This doesn't seem AA'ed either... reason I'm bringing this up is to find a way to make the gap between the DS and the PSP smaller..

Last edited by Spaceface on Fri Dec 24, 2004 12:14 pm; edited 1 time in total

Spaceface wrote:

is 1xAA a limit creatd by N or by the programmers?

I agree with telamon. It's probably a hardware limit, or at least only possible to do 2x on more simple scenes than those found in SM64DS unless done in software.

But in the case of software, it would cause massive CPU drain because you would have to either:

draw everything in software

or

draw landscape (ground, hills) in the far distance w/ hardware, copy to a buffer, copy everything in the not-so-far distance to another buffer w/hardware, blend the two together, moving closer and closer. Then, doing the same thing with scenery (flowers, trees, clouds) but over top of the landscape. Then, finally doing the same thing with objects and characters, but over top of everything else done so far.

I'm not a very efficient programmer, and as a result have an uncanny knack to think of the most CPU wasteful ways of doing things, so keep in mind these are just the two ways I can think of making better looking scenes.

Er, just thought of another way, dunno if it's possible. Render the scene 4x the size (2x wider and 2x taller) into a buffer, then using a smart software scale shrink it down to the regular screen size. I call this Matt's 4x Non-De-Anti-Aliasing. But if someone has already thought of and created this method, then whatever they called it is the real name... :)

Spaceface wrote:

This doesn't seem AA'ed either...

If you mean the tree, that's not an AA problem, that's a texture issue. The DS really, REALLY, needed better HW texture support. You'd think with 4MB of memory they could've done better (don't know if that 4MB is accessible to the video, though... the video, as I know it, has some weird number like 656 KB). Still, just some bilinear filtering would have been nice.

hmm yeah, maybe in that case I mean the texturing... any chance that'll be more detailed in a later game-development stage?

Good lord, I sure hope so... I sure hope so...

It's almost always been the case that early games don't look as good as games made a year or two after a system's release, so we'll have to wait and see! Or crack the DS wireless and send some homebrew demos showing off what the DS is capable of, and use that to gauge how good games COULD look.

yeah, later games always look much better...just compare super mario 64 to zelda: ocarina of time to see what i mean, or even banjo-kazooie to banjo-tooie
i do a fair bit of 3D work, so i'll try some things with 1x, 2x, 4x and no AA, as well as some different texture resolutions once i can get them onto the ds

Sebbo wrote:

yeah, later games always look much better...just compare super mario 64 to zelda: ocarina of time to see what i mean, or even banjo-kazooie to banjo-tooie
i do a fair bit of 3D work, so i'll try some things with 1x, 2x, 4x and no AA, as well as some different texture resolutions once i can get them onto the ds

I don't think the DS does super-sampling AA, because only actual polygon edges appear smoothed in the screenshots I've seen - if it was doing FSAA then alpha-test borders would also be smoothed and so would the boundaries between texels.

I think the biggest visual improvements will come from games tailored to the systems strengths:

Noisy, high-contrast textures look ugly
Low-contrast textures look ok
Textures containing bold, simple features look ok
Smooth-shading looks good

Basically, the system appears to heavily favour the Nintendo style. Games going for photorealistic visuals are going to look inferior IMHO.

Spaceface wrote:

I was wondering; everyone saw how the DS displays kinda pixelish graphics.

This tiger woods screencapture has been *scaled up*, unless somebody out there has a special DS with a 460x345 resolution. ;)

So there's not much you can glean from this. Any image that's scaled up (especially to a weird size) will get pretty mangled at a pixel level, and some graphics tools do a really awful job at this. It's certainly going to look more "pixelish" and any AA that was there originally is impossible to distinguish from the scaling side effects.

Anyone have a clue how they get these screen captures? Is it likely that the DS dev hardware has a a screen capture capability, or is it more likely that it's off of a Nintendo-made emulator? The differences in gamma alone could lead to some misleading artifacts if you're adjusting the levels for release to the press, especially with "noisy" textures.

-Scott

I'm guessing that, considering the very short development time for the current batch of DS games that we'll see an increase in vsual quality, especially in in texture sizes and filtering. Afterall the PS2 doesn't have hardware AA but they still coded it into graphically intensive games without a performance hit (EU Tekken Tag for example)

I believe Metroid Prime Hunter uses AA, turn into a ball and see for yourself.

Spaceface wrote:

reason I'm bringing this up is to find a way to make the gap between the DS and the PSP smaller..

which gap? the technology gap or the price gap? Personally, I'm quite happy with the capabilities of the DS considering how much more powerful it is than the GBA SP that I purchased a little over a year and a half ago.

The PSP looks neat, but the price is what's turning me away. Until the PSP can run homebrew code, I'll probably continue to stay away.
_________________
dennis

The Nintendo DS does NOT use AA in any form. The smooth edges is due to the higher poly count, not AA. The textures do not use any filtering whatsoever. Nintendo talked about this and they said since the screen is so small, you dont really need it. Plus we can use those extra bits of CPU cycles for more polygons.

I work on 3D graphics for games and I can tell you without a doubt that AA does NOT exsist on the Nintendo DS to date.
_________________
DigiPen Graduate

DrEggman wrote:

The Nintendo DS does NOT use AA in any form. The smooth edges is due to the higher poly count, not AA. The textures do not use any filtering whatsoever. Nintendo talked about this and they said since the screen is so small, you dont really need it. Plus we can use those extra bits of CPU cycles for more polygons.

I work on 3D graphics for games and I can tell you without a doubt that AA does NOT exsist on the Nintendo DS to date.

Not that I'm calling you a liar, because it seems you know what you're talking about, but how do you explain the fact that if you zoom in on Mario 64 and look closely you can see anti-aliased edges? Go onto the main bridge in front of the castle, and zoom in so that the cement handrail covers half the screen.

I believe you when you say the DS doesn't have AA, but still SOMEthing is being done here. Maybe you know?

mymateo wrote:

I believe you when you say the DS doesn't have AA, but still SOMEthing is being done here. Maybe you know?

Maybe THIS AA is some subpixel trickery instead of being a true AA?

That sounds silly :) What I mean is that instead of working out per pixel how to AA a line, it instead has a special mode that, for lack of a better programming term, was called AA, but instead of doing a per pixel calculation display, it has a mode where each pixel in a group is treated as an individual pixel.

Could this mean you'd have the "effect" of AA without the overhead?

Or the models could have been drawn with AA lines, making preproccessed AA.

DrEggman wrote:

The Nintendo DS does NOT use AA in any form. The smooth edges is due to the higher poly count, not AA. The textures do not use any filtering whatsoever. Nintendo talked about this and they said since the screen is so small, you dont really need it. Plus we can use those extra bits of CPU cycles for more polygons.

I work on 3D graphics for games and I can tell you without a doubt that AA does NOT exsist on the Nintendo DS to date.

I am however calling you a liar, since the Nintendo DS can do antialiasing(note, I have no idea if it's hardware or software, but from what I've seen it should be hardware). Antialiasing is not a programming term, it's a technique used to anti the aliasing (weiii), which the DS does feature(just take a look at Mario 64 DS). Sure, it's probably to slow to handle FSAA, but some kind of AA is in that can o' gaming.
And we where never talking about any texture filtering here, which the DS does not feature(atleast not from what I've seen, and if it does, it would be really weird that no one uses it(although you could perhaps fake it somehow))

I don't see how the DS can do FS AA of any kind. To do that you would need a frame buffer.

It might be possible for it to do AA on triangle edges, but somehow I doubt it. To do so, the hardware would have to sort/rasterize triangles back to front. Since there appears to be no full framebuffer (and therefure no full z-buffer), chances are the 3D core scanline-intersects all the triangles for that frame, draws all triangles appearing on scanline 0, then 1, then 2, etc, using a small z-buffer of height 1 (almost equivalent to how PowerVR and similar hardware do it). Using any z-buffer means no depth sorting needs to takes place, which makes AA on triangle lines impossible.

And obviously, no texture filtering of any kind.

I'd have to go with sub-pixel trickery to get some sort of pseudo-AA on triangle edges. Either that or rendering doesn't use any z-buffer at all, which means back-to-front sorting is needed regardless of AA, and in this case AA would be a freebie.
_________________
outRider

Sub-pixel trickery is likely, and it's even more likely in hardware given that Nintendo can change the BIOS to match the RGB vs. BGR characteristic of the screen. Frame-to-frame random jitter of camera coordinates, taking advantage of the slow LCD, is also likely.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

it might not be hardware AA, but possibly software AA
either that, or i'm thinking, going by DrEggMan, that LODs are being used
"For example, imagine you are building a small town. You create a park with some benches and a path. Off in the distance, there is a house. When you are in the park, the house looks like a tiny box. You can limit the detail of the house, perhaps by just using a primitive cube for it. But what happens when you move towards the house? Eventually, the house will fill the screen. Now it is obvious that it is only a simple cube.

This is where the Levels of Detail (or LOD) feature helps. A Levels of Detail object (or group) contains different versions of the same object, from simple to complex
Let's return to our example above. You can create a simple cube to represent the house at a distance. For a closer view, you can create another house with some simple windows and doors. And for the close-up version, you can add as much detail as you want: window sills, awnings, brick walls, and so on. You can create as many LODs as you want. If you then group these LODs together, the various LODs will automatically be revealed as you move towards and away from the object. So, when the object is far away, the simplicity of it will improve performance during navigation. When the object is close, you will see all the detail built into the object." (straight from the help file of my 3D modeller and animator :-P)

Sebbo wrote:

it might not be hardware AA, but possibly software AA
either that, or i'm thinking, going by DrEggMan, that LODs are being used.

I don't think LODs are related to AA, but I might be wrong.

netdroid9 wrote:

Sebbo wrote:

it might not be hardware AA, but possibly software AA
either that, or i'm thinking, going by DrEggMan, that LODs are being used.

I don't think LODs are related to AA, but I might be wrong.

No, you're completly right. LODs only (atleast usually, they might have to do with textures and other stuff too, but almost never AA) have to do with the polygon count of models.

There does appear to be some form of edge antialiasing in Mario, where walls meet the floor in the castle, for example. Compare these edges to the non-antialised edges of Mario's shadow, for example.

Hopefully this is a feature that future games can make better use of. But it still seems pretty pointless, as it's the lack of bilinear texture filtering that's giving DS games the nasty PS1-like look. Which is a shame, as it makes Mario 64 look significantly worse than the N64 version :(

It must have been a tough call to not include such an important feature, probably to save on cost, but possibly to save on power consumption?

Mario 64 DS has higher polygons in models than N64 version, if you check screenshots of old N64, you will realise what a big improvement the DS version is.

Sure there is pixelization, but some games it's less obvious like Metroid Prime hunters which i think looks as good as GC version but with some lacking visual effects.

Anyways such things shouldn't bother anyone if they are having fun.

Guys, DS hasn't got ani kind of dedicated 3-D hardware. The processor dedicated to render the computer graphics is an ARM-9. That's the reason there's NO kind of AA, not even texture filtering. And I don't belive it to ever be possible. The only thing it could do would be tricks using the framebuffer to blend 2 addiacent frames and thus blending the images (making then even blurrier as this tecnique is called motion blur and usualii blends more than 2 frames).

xabib wrote:

Guys, DS hasn't got ani kind of dedicated 3-D hardware. The processor dedicated to render the computer graphics is an ARM-9. That's the reason there's NO kind of AA, not even texture filtering. And I don't belive it to ever be possible. The only thing it could do would be tricks using the framebuffer to blend 2 addiacent frames and thus blending the images (making then even blurrier as this tecnique is called motion blur and usualii blends more than 2 frames).

N64 didn't have either if i remember correctly, yet had certain effects.

xabib wrote:

That's the reason there's NO kind of AA, not even texture filtering. And I don't belive it to ever be possible. The only thing it could do would be tricks using the framebuffer to blend 2 addiacent frames and thus blending the images (making then even blurrier as this tecnique is called motion blur and usualii blends more than 2 frames).

Sometimes people should check things before they post.

Super Mario 64 DS does use antialiasing(and I think Metroid, but I'm not sure of that, haven't looked). And the antialiasing we are speaking of does not have anything to do with texture filtering. And it's not motionblurring either, it's simply antialiasing.

This brings me to something I have wondered about for a while.

DOES the DS have 3D hardware at all or is the previous comment about the ARM9 doing all the rendering in software true?

I don't recall ever reading anything stating it DOES have 3D hardware, just a quote of how many polygons the DS should be able to push.

Seeing as the GBA could do basic 3D in software it might be possible the vastly superior ARPM9 could handle 3D graphics this well. However as im no programmer I have no realistic idea if this is possible or not.

It has been said though that the DS is more powerful at 3D than the GP32 BECAUSE it has 3D hardware, so again - does it or does it not?
_________________
[Images not permitted - Click here to view it]

[Images not permitted - Click here to view it]

ras wrote:

Sometimes people should check things before they post.

Super Mario 64 DS does use antialiasing(and I think Metroid, but I'm not sure of that, haven't looked). And the antialiasing we are speaking of does not have anything to do with texture filtering. And it's not motionblurring either, it's simply antialiasing.

Pardon me mister expert. Can you explain to all the people what antialiasing consists of?? Nooo? Well, I'll tell you. In a very ROUGH way AA consists on rendering the scene at a higher resolution and then scaling it back to the native resolution. Of course nowadays this tecnique is performed in very different ways because it needs lots of optimizations for not being so heavy.
To do this calculations graphic cards have very specialized hardware capable of doing texture scaling operations at incredible speed.
DS has no graphics specialized hardware, only a few registers and operations in the ARM9 maybe.
Nintendo64 had AA. DS hasnt. Call it whatever, but I assure you DS can't do AA, and if it can its because Nintendo has lied about the hardware (which I doubt). Of course there are other techniques besides AA to soften hard edges...

eh? I always learned that AA was a technique that calculates the needed extra pixels inbetween. Wouldn't scaling stuff like that have an opposite effect?

xabib wrote:

DS has no graphics specialized hardware, only a few registers and operations in the ARM9 maybe.

The DS has perspective correct texturing. Something which is not easy to do on quickly and accurately on an ARM chip without a divide instruction.

Just from playing and observing Mario64 DS, observing the gouraud shading, mostly-accurate z-sorting, perspective correct texturing, accurate clipping, edge antialiasing, and translucency, I think there's definitely some graphics hardware at work.

If it's a software renderer, it'd have to be rather l33t to do all that at a good speed, with the all game code running on the same CPU

ras wrote:

Can you explain to all the people what antialiasing consists of?? Nooo? Well, I'll tell you. In a very ROUGH way AA consists on rendering the scene at a higher resolution and then scaling it back to the native resolution. Of course nowadays this tecnique is performed in very different ways because it needs lots of optimizations for not being so heavy.

Supersampling (what you describe) is only one way to do antialiasing; there are many others, and they can all create a good final image.

There are many ways hardware like the DS could do polygon edge antialiasing, especially if it has a one-line buffer as has been suggested. If it was fairly simple - for example, an extra pass only on pixels where a near-vertical (the most noticable aliasing) edge occured - it could be done with only a slight performance drop.

I'm not saying it does do antialiasing, just that there are methods that could be used.

There isnt any edge AA. When you compare a edge to mario's shadow, you have to realize that Mario's shadow isnt a polygon, well it is a poly, but a textured one. You dont need edge AA for a screen with that dpi. It just wouldnt be that noticeable. Most of everyone here is used to AA in a TV or PC monitor format where it is noticeable. But with the DS screens, you simply do not need it whatsoever. Guess what? Nintendo realized this so they left it out.
_________________
DigiPen Graduate

We sure are going round in circles here, nobody seems able to prove one way or the other.

I guess we have to wait until homebrew gets going on the DS so it can be proven.
_________________
[Images not permitted - Click here to view it]

[Images not permitted - Click here to view it]

It's very simple

Look closely at the graphics - THE EDGES ARE SMOOTHENED. (Is that a real word?)

So obviously, there's SOMEthing being done, call it what you want. It might be hardware, it might be software, and the truth is we won't know for 100% certain until either (A) we (not including me) crack the DS one way or another and learn its secrets, or (B) Nintendo releases a total specs sheet.

I don't know about anyone else, but I'm getting a little tired of people actually getting upset at eachother for voicing their opinions. What do I believe? I believe the DS has some kind of 3D rendering hardware, and that the DS has an AA option in it. Am I right? I don't know, and we can only speculate for now.

http://www.lik-sang.com/news.php?artc=3530

Well, if there's some specialized 3d hardware I cant see it anywhere. Yes, its true that there are other ways of doing AA but its ridiculous. With the size and resolution of the screens who wants AA there. My OPINION is that theres no AA, the image is simply too small to have hard edges. Its like doing AA on a 320X240 image... its pointless. Its true that DS seems to make some sort of texture correction but that's as far as I can tell. And yes its impressive if it's doing that on an ARM9 only. Maybe Nintendo figured out a way to make a very optimized 3d software engine for the ARM9 platform. Time will tell...

xabib wrote:

Well, if there's some specialized 3d hardware I cant see it anywhere.

What does "specialized 3d hardware" look like?
Where are the 2 cpus, ram, 2D hardware and sound chip?
_________________
I probably suck, my not is a programmer.

I highly doubt the 3D rendering is entirely in software. While there does seem to be a bit of a debate on whether there can be 3D on both scren at the same time, and what sort of trickery would be needed, there is definately *some* sort of significant limitation to getting 3D on both screens at the same time. If the 3D was done 100% in software then there is no way that would even be an issue.

BTW, I thought I heared somewhere that the DS had a hardware divide?

grml, misinformation going on..

Yes, the DS has 3D graphics hardware, capable of T&L (4 hardware lights) and perspective correct rasterization with no bilinear filtering :(. All matrix transform and vector math is done in fixed point, mostly in 1.19.12 (sign/whole/frac) if i've understood correctly.

Ector, I would be very pleased to know where you got that information. No joking.

xabib wrote:

Ector, I would be very pleased to know where you got that information. No joking.

Look at memorymap.txt on www.darkfader.net

Toon table?? Cel-Shading via hardware??. Besides all the matrices, texture, lights, poligons registers. It seems there is some sort of hardware acceleration... However, where is this info from?

xabib wrote:

Toon table?? Cel-Shading via hardware??. Besides all the matrices, texture, lights, poligons registers. It seems there is some sort of hardware acceleration... However, where is this info from?

Leaked memory map.
_________________
Little kids and Playstation 2's don't mix. :(

Nintendo did state officially that it can do cel shading I seem to remember.

IIRC ARM processors are customised for each client so they may have added a few instructions key to cel shading and a few other effects

From what I've seen, customization of processors typically doesn't come in the form of "added instructions". The only customizations in the GBA's ARM7TDMI CPU are memory-mapped I/O peripherals.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Just Checked over the Metroid Hunters Demo

and there's certainly no Anti Aliasing going on - fullscreen or edge

in fact if you closely enough at any high contrast textures you can see how poor the perspective correct texture mapper is - it must use 32bit fixed point for it to lose precision so quickly. In fact at certain angles the whole illusion falls apart and the texturing becomes very "watery"!!

Another thing I've noticed - there's no mip mapping!!! gah - thats a must for several reason (actually this could explain the lack of uv precision - see above).

but there is some wierd ass stuff going on with the wireframe rendering - on the regulator level get to the diagonal tunnel thats wireframe with a rotating texture - and look at the very first hexagon segment - the top lines are doing wierd shading - almost like they tried to wu-lines but got the algo' wrong? - maybe this is done in software?

Keep in mind this is a demo, there is obviously a lot of tweaking to do.

Not only are there graphical problems, but I have gone right through solid objects while playing.

It is safe to assume the engine is going to get a lot of reworking before release.

At least DS has dynamic lighting.

http://www.gamespot.com/ds/action/supermariobrosds/screens.html?page=2

Look at the goomba and mario.

You mean gouroud shading?

Nah, if you look at the pictures (especially the next one in series) it seems dynamically lit. Not like that's impressive; my Mac running Marathon in 1995 did the same thing.
_________________
Rav (Win/Mac/Linux games for free)

1. From the leaked register map, it's almost certain that there is hardware based 3d.

2. Anti-aliasing by rendering a larger picture and scaling it back with oversampling is only one way to achieve AA, called FSAA (full screen anti-aliasing). It costs lots of memory and bandwidth, however there are other ways to achieve AA, even if the result is less pretty.

3. The outstanding pixelisation problems that can be seen in DS games come from the fact that there is no bilinear filtering. Bilinear filtering does more for the rendering quality than AA.

4. I'm pretty sure that the DS does AA. Perhaps they could do a limited form of AA easily and without complicating the hardware too much because of the way they seem to render polygons (line-by-line, on the fly, as it is rumored). Otherwise I don't think they'd have done it, it's kind of a waste to spend resources on doing that when you don't even have bilinear filtering.

Another interesting fact that would tend to point toward hardware based 3d is an article, in an old issue of edge (perhaps one year or two ago, don't remember). It was an interview of a guy from ARM, where he explained that it was them who designed the GBA's hardware, and they were working on a very low power consumption, low transistor count 3d chip for nintendo, that could fit in a portable system.

Im starting to think what people are associating as AA is in fact just JPEG artifacts on the images.

While playing Mario 64 I had a look at the screen, the only thing that looked smoothed at the edges were the floor and im sure there are other sticks involved with large floor surfaces that might work better than AA as the tiles are so small.
_________________
[Images not permitted - Click here to view it]

[Images not permitted - Click here to view it]

I'm not basing what I say on pictures found on the net. There are antialiasing that can be noticed in metroid.

There is some very noticeable instances of anti-aliasing on 3d in feel the magic, thanks to the minimalist artwork style.

For instance, the yacht minigame exhibit clearly noticeable antialiasing, as well as 3d on both screens.

zlodo:I'm not basing what I say on pictures found on the net. There are antialiasing that can be noticed in metroid.

dude - can you tell where exactly in the metroid demo you've seen anti aliasing - I can't find it anywhere?

IT's hard t see, essentially because most of the high contrast edges you see in game are textures patterns, which don't seem to be antialiased, and there's no bilinear filtering.

It seems that when the DS does AA, it's only on polygon edges.

Try to approach a gate, but don't open it. It's easy to see on a closed gate because there's usually a good contrast between the light blue of the gate and the dark wall.
Look at the top edge of the gate. Turn slightly, so it's not perfectly horizontal.
Antialiasingcan definately be noticed there.

Since it's only on polygon edges (and apparently, not even on all of them), and there's no texture filtering, it's basically useless. But it's there.

Zlodo wrote:

Since it's only on polygon edges (and apparently, not even on all of them), and there's no texture filtering, it's basically useless. But it's there.

Thinking about it a bit more, it does have one good use - for small, detailed models with subtle animation, such as Mario himself - to hide the low resolution of the screen a bit.

Nothing will make up for the lack of bilinear filtering, but an untextured game, maybe something a bit Rez-like, could look great!

I think you guys are seeing AA in something very simple. LCD screens arent 100% accurate, there's always a small amount of blurring (even on TFT LCDs I can see the blurriness) and you may be thinking thats is AA. I wont say AA isnt possible on DS, but I believe its nor practical. If DS had the power to do AA then i would use that power to fileter textures. That would be 100 times more useful than AA.

I have only ever seem blurring on a TFT LCD with fast movement. I believe part of the POINT with LCDs is that they ARE accurate, extremely clear indeed. This is in fact why even though the DS is a small screen its still VERY easy to pick out the pixels. Nintendo seem to think we are all blind. The ONLY way we wouldnt have seen them so easily is if the DS had used MUCH higher resolution screens at the same physical size, in other words a MUCH smaller dot pitch.

The best example being on a PC. You stick your monitor in a resolution so high you would have trouble reading the text. Now run a game in that resolution. The pixels are so small, AA is not really necessary.

The fact is the Nintendo rubbish that texture filtering isnt needed is just that, pure bull crap. Unless you are using stupidly hires textures you will ALWAYS need some level of filtering, its just too damn easy to see the crappy textures especially on Metroid. Its true that its not essential, but its going to be the thing that pushes some people to the PSP. Some people are shallow creatures who just couldnt handle the idea of buying a console that has big blocky textures.
_________________
[Images not permitted - Click here to view it]

[Images not permitted - Click here to view it]

xabib wrote:

I think you guys are seeing AA in something very simple. LCD screens arent 100% accurate, there's always a small amount of blurring (even on TFT LCDs I can see the blurriness) and you may be thinking thats is AA. I wont say AA isnt possible on DS, but I believe its nor practical. If DS had the power to do AA then i would use that power to fileter textures. That would be 100 times more useful than AA.

Where there is no AA (high contrast edges within textures, polygon edges that are not antialiased), you can perfectly distinguish the pixels. There is no blurring effect due to the LCD.

Quote:

If DS had the power to do AA then i would use that power to fileter textures. That would be 100 times more useful than AA.

Maybe they simply had an opportunity to do AA easily because of the way the hard is designed.

Folks, polygon edge AA isn't trivial. Even your bleeding edge Geforce 6800s and Radeon X800s won't do edge AA. Instead, they've preferred FSAA, which eats up fillrate like there's no tomorrow. Think about it, edge AA is expensive, so expensive that cutting edge consumer 3D hardware would rather process the entire framebuffer at 4x the resolution than deal with pixel-thin triangle edges, because at the end of the day it's still a lot cheaper.

The reason is simple. To do edge AA you have to render each and every triangle back-to-front. Sorting every single triangle back-to-front every single frame is expensive. Not only that, but drawing everything back to front eats up fillrate for nothing, since you're potentially drawing over every pixel many many times. Not to mention that the hardware is probably already testing every triangle against every scanline, and that amounts to an impossible amount of sorting per frame.

Further more, every single triangle edge would have to be drawn with alpha blending enabled, eating up even more fillrate.

Forget about bilinear filtering, it would be braindead for Nintendo to build a machine that does edge AA period.

But really who cares? You don't go to war with the machine you wish you had, you go to war with the machine you have at the time (ahem...). PSX games did it just fine.
_________________
outRider

Last edited by outRider on Fri Dec 31, 2004 6:21 am; edited 1 time in total

Alex Atkin UK wrote:

I have only ever seem blurring on a TFT LCD with fast movement.

Then create "fast movement" of the textures within each poly. Consider frame-to-frame random subtexel jitter of texture coordinates as a way to get the LCD to do your texture filtering, unless the DS requires rounding texture coordinates to integers at each vertex.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

outRider wrote:

Folks, polygon edge AA isn't trivial. Even your bleeding edge Geforce 6800s and Radeon X800s won't do edge AA...The reason is simple. To do edge AA you have to render each and every triangle back-to-front.

I fully agree that it'd be silly for the DS to do it, but I do need to point out that there are methods for doing edge antialiasing that don't require this approach. The tile method used on the Dreamcast, for one - I don't recall Dreamcast games using it, but they Kyro graphics card that was based on the Power VR did offer edge antialiasing with this method.

kerrle wrote:

I fully agree that it'd be silly for the DS to do it, but I do need to point out that there are methods for doing edge antialiasing that don't require this approach. The tile method used on the Dreamcast, for one - I don't recall Dreamcast games using it, but they Kyro graphics card that was based on the Power VR did offer edge antialiasing with this method.

The PowerVR chips actually did something closer to FSAA, not edge AA. To anti-alias triangle edges you have to blend them with what's behind, so what's behind has to either already be in the framebuffer (back-to-front), or your framebuffer has to support destination alpha (front-to-back AA is possibly with this), but either way your triangles have to be sorted per frame. Cards as far back as Voodoo2 supported edge anti-aliasing, but you had to provide sorted triangles per frame yourself (using the CPU).

PowerVR's tile method is similar to what the DS (supposedly) uses. At that point in time a fullscreen zbuffer was unheard of, it was expensive and memory latency was still high. The PVR cards didn't have a fullscreen zbuffer, instead they had a tile-sized zbuffer, and the framebuffer was divided into tiles. All triangles intersecting the first tile were drawn with zbuffering enabled, then all triangles intersecting the 2nd, and so on. Using a zbuffer for HSR frees you from having to sort triangles, which you should avoid like the plague. Using a small zbuffer overcame the high latency of zbuffering at the time.

Once a tile was drawn it was copied to the framebuffer. A 32x32 tile might represented a 16x16 area of the framebuffer, so the tile would be scaled down via bilinear or bicubic enterpolation, which basically amounts to FSAA via supersampling done tile by tile.

The DS probably uses the same approach on a scanline level, without the final framebuffer, or any filtering.
_________________
outRider

Isn't edge-based AA expensive because you have to sort the polys and then trace their edges?
_________________
Rav (Win/Mac/Linux games for free)

ravuya wrote:

Isn't edge-based AA expensive because you have to sort the polys and then trace their edges?

If you have perfectly sorted polygons/spans, edge AA is fairly trivial. This may suit the DS nicely, if the speculation about framebufferless rendering and polys-per-line limits is true - if there's no z-buffer, the polygons are being sorted in some other way, and if they're sorted, adding edge AA is quite easy.

If you rely on a z-buffer, and therefore can draw polys in any order, like modern ATI/NVidia cards, you can't do edge AA. So FSAA is used instead.

re: the DS's AA on polygon edges.

If the DS doesn't have a framebuffer, then it might be drawing scanlines with a linked list structure. My apologies to those who don't know off the top of their head what I'm referring to, but it's far too late to try to write a couple of paragraphs describing the technique (it's fairly esoteric and implementing it is rather complicated and more useful to 2d games, but has the advantage of completely eliminating overdraw - and when you only have 200mhz - or only 90mhz - you want to avoid all the extra work that you can!).

I remember implementing edge-based sprite rendering in an engine I was working on once (16bit, with all the blitting was done with memcpy). I did it like this: when constructing my scanline lists, I'd 'overdraw' each scan by one pixel to the right. Then I would 'mix' the first pixel of the next scan with the overdrawn pixel, and finally memcpy the rest of the scan as normal. After optimizing the blending as much as I could, rendering an entire frame took around 5-10% longer than it would take without the blending.

Could the DS be doing something similar to this? If it handled the scanlines and blending like this in hardware, it would take no extra effort at all to blend those edges.

arbitrary wrote:

ravuya wrote:

Isn't edge-based AA expensive because you have to sort the polys and then trace their edges?

If you have perfectly sorted polygons/spans, edge AA is fairly trivial. This may suit the DS nicely, if the speculation about framebufferless rendering and polys-per-line limits is true - if there's no z-buffer, the polygons are being sorted in some other way, and if they're sorted, adding edge AA is quite easy.

If you rely on a z-buffer, and therefore can draw polys in any order, like modern ATI/NVidia cards, you can't do edge AA. So FSAA is used instead.

Ohh, I get it now. Thanks :) I've only ever written FSAA algos, and they looked awful.
_________________
Rav (Win/Mac/Linux games for free)

outRider wrote:

But really who cares? You don't go to war with the machine you wish you had, you go to war with the machine you have at the time (ahem...). PSX games did it just fine.

Does this mean we need to go to the junkyard and scrounge up hardware that will do AA? :)

--Kumba
_________________
"Everybody has a right to be stupid, but some people abuse the privilege."

--Joseph Stalin

Andor wrote:

Could the DS be doing something similar to this? If it handled the scanlines and blending like this in hardware, it would take no extra effort at all to blend those edges.

My *guess* is that the DS rasterizer may have been designed as an extension of the GBA sprite hardware - and spans of polys are handled in a very similar way to how the GBA handled rotated/scaled sprites - this would explain any polys/scanline limit that may exist.

This would need a lot of setup per scanline, which would probably need doing in hardware, but maybe could done on one of the CPUs, with an awful lot of hblank DMA?

Maybe it's nothing like that.... but 'framebufferless' seems a very odd way of doing things...

Andor wrote:

re: the DS's AA on polygon edges.

If the DS doesn't have a framebuffer, then it might be drawing scanlines with a linked list structure. My apologies to those who don't know off the top of their head what I'm referring to, but it's far too late to try to write a couple of paragraphs describing the technique (it's fairly esoteric and implementing it is rather complicated and more useful to 2d games, but has the advantage of completely eliminating overdraw - and when you only have 200mhz - or only 90mhz - you want to avoid all the extra work that you can!).

These methods (that I saw called span buffer or edge lists) works well for software rendering. IIRC, that's the method the first quake was using.

However, I think there is some sort of z-buffering: I had a bug once in asphalt GT where a car I collided into got stuck halfway through the road, and intersected properly with it.

Come to think about it, the antialiasing (that I'm still convinced is in, regardless of how silly it may sound) seems to be a bit applied on a random basis. It could very well mean that they simply don't sort the polygons, and thus depending on the drawing order, some polygons would exhibit antialiased edges, and for others, the antialiasing would be overwritten by the background polygon if it's draw afterward (which would mean they anti-aliasing impementation would add pixels at the border to perform the AA, but would not write these in the z-buffer)

For those who have feel the magic, try launching the yacht minigame. Pause the game, so you're sure that you don't mistake movement and remanence of the LCD for AA. Pay attention to the edge between the sail and the pole (unpause and blow slightly to turn the sail around, if needed). The sail is white, the pole is black, and that edge is slightly slopped.
You should distinguish the aliasing effect clearly along that edge, but you don't.

For reference, look at the girl in the story mode game selection menu: there is no AA there, and the edge of her arms and legs against the orange background are clearly pixelated.

You all still miss the main point. The screens are small. Do you honestly believe Nintendo would waist any CPU cycles to have AA on something so small that you wouldnt even notice? Hell, PS2 rarely has AA and you expect the DS to use it? What I see on the screen is smooth edges due to screen size, not AA.
_________________
DigiPen Graduate

The fact remains that there is an intermediate pixel present between a poly edge and the background in some games at least - going into 'first person view' in Mario DS shows this last time I did it.

How it is done, whether in software for particular titles or whether the hardware does it, will be interesting to find out.

The GBA was allegedly largely designed by ARM, and apparently (some people have said on very good authority) they had a more advanced design for the GBA long before, and the retail GBA was a cut down version of it. ARM have VideoLogic/PowerVR as a tech, I wouldn't be surprised if there wasn't something at least learned from that tech.

DrEggman wrote:

You all still miss the main point. The screens are small. Do you honestly believe Nintendo would waist any CPU cycles to have AA on something so small that you wouldnt even notice? Hell, PS2 rarely has AA and you expect the DS to use it? What I see on the screen is smooth edges due to screen size, not AA.

Whatever. I've pointed at places where edges are smooth, others where they aren't. The later proves that despite the screen size, the individual pixels can still be distinguished (well, maybe it depends on the person. I'm short sighted and I see tiny thing very clearly from close up). CPU cycles have nothing to do with it if it's rasterized by the hard, and I doubt it's software rendering.

I'm not saying AA is something that would make sense on the DS, only that a variant of it is there.

Zlodo wrote:

CPU cycles have nothing to do with it if it's rasterized by the hard

What about PPU cycles? I seem to remember that the GBA PPU had a limit on how many sprite pixels it could render in the scanline based on rendering time within a scanline, and I'd imagine that the DS PPU has time limits as well.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I think this unlikely, but since the DS is capable of making the black boarders for cel-shading (http://media.ds.ign.com/media/682/682844/img_2139895.html) then perhaps some of the AA we are seeing is some variation of this effect. ( I know the image above is grainy around the edges, but keep in mind it is not a screen shot and has been blown up. )

Anyway, it was just a thought.
_________________
Shell Smash: 55730
Bounce and Trounce: 163

tepples: might be a problem indeed.

kaeru: now that could explain why they'd have done aa: it may share some of the logic needed to perform that black border rendering (if there is any), and thus anti-aliasing might not have costed them much to add from there.

After playing Mario DS for a while, there is, without a doubt, some variant of (edge?) AA going on in Mario DS. I make no claims as to how they do it, but they certainly are doing something.

In certain cases, it seems to either be turned off (on certain characters??) or break down with certain viewing angles??...in which cases, it becomes very obvious.

A specific character is one of the yellow bunnies while playing as yoshi. In a certain underground area where there are dark blue-gray walls, the pixely edge contrast is horribly noticeable. (use the camera button to pull in for a closer view)

So, after taking Mario and Wario for a spin in the same area, the edges on Mario's white gloves and Wario's general yellow colour don't behave at all the same.

There were plenty of other cases to find without much effort.

Maybe due to the properties of the LCD, low contrast edges appear softer than high contrast edges?

I don't see how or why actual AA would be applied arbitrarily in some instances and not in others.
_________________
outRider

I didn't believe it either, but I think they're right. Outside the castle (in the starting area), stand on the top of the stone ramp that leads down to the empty moat. Turn and face the waterfall, and in front of the earthy cliff, where the edge of the stone is in front of dirt, you can see some fairly clear antialiasing in the over-the-shoulder view. It's visible on pretty much every edge, except for where the transparent water meets the wall enclosing it, but it's particularly noticable on the raised stone ledge, where it faces the earthy-cliff. Here's a picture of the location I mean:

[Images not permitted - Click here to view it]

I'm quite familiar with LCD screens, having written a sub-pixel font renderer for the GBA, and this doesn't look like an effect that would be caused by something as simple as the sub-pixel order or anything like that. Also, it remains even when the scene is stationary.

EDIT:
It's quite visible, as I've said, on most of the edges in this scene, but oddly, the stone area right below this (if you look down over the edge) clearly has absolutely no smoothing; the edge is as jagged as can be. It really makes the smoothed lines even more obvious.

i only just got mario 64 today (got it late cos it was sold out in the US, and i live in australia), and i'd agree that there is edge softening (like what you see in jpgs between an objects edge and the background if u zoom in). go to the hedges at the start of the game and there's some brick walls. zoom right in behind yoshi and start making yoshi turn in circles until u can see it - the edge of the wall smooths with the grass behind it(it remains even when you're not moving)
i'd say that the edge softening only applies to static objects, cos zoomed up close on yoshi i could only see hard edges

WARNING: Potential spoilers.

Yep, some edges are smoothed and others aren't, heh. And when they aren't they really stand out from the smoothed edges.

Another example is in the octangonal room (with the aquariums) you can reach from the main interior castle area...there are polygonal, non-textured, and alpha'd light beams coming out of the tanks. These edges are clearly not smoothed at all.

Sort of off-topic, but related to alpha blended triangles, etc. They would need to be sorted back-to-front ...and rendered back-to-front...in order to work correctly. I'm not entirely sure that they are doing this sorting though, at least not in all cases. Note, this really only applies to rendering alpha'd triangles against each other.

An example is in Lethal Lava Land. Just to the left of the player start is a small island with an alpha'd faceted globe where the star will appear when you've completed the red coin part. If you go to this island and look around, you'll typically see lava bubbles (placed as decals on the lava surface) drawing over top of the globe.

In case there was any question, Metroid also has smoothing that operates in a similar quirky manner. The wireframe lines someone mentioned earlier don't seem to be AA'd, but the edges of most (all?) models are.

Guys why are you trying so hard in speculation.

Why not just call or email nintendo and ask?

Nintendo probably won't divulge anything except to NDA parties, and NDA parties can't divulge anything on gbadev.org.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I think I just pretty much proved that the DS does antialiasing; I did what should have been the obvious thing.

I compared uncompressed, official screenshots of Mario 64 taken from the press kit, and enlarged areas that show antialiasing.

Below are links to three screenshots which have had sections enlarged, so that the effect can be easily seen. They're fairly big, as I didn't want compression artifacts to confuse people.

[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]

But I think you'll agree that it's pretty obvious.

kerrle wrote:

I think I just pretty much proved that the DS does antialiasing; I did what should have been the obvious thing.

I compared uncompressed, official screenshots of Mario 64 taken from the press kit, and enlarged areas that show antialiasing.

Below are links to three screenshots which have had sections enlarged, so that the effect can be easily seen. They're fairly big, as I didn't want compression artifacts to confuse people.

[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]

But I think you'll agree that it's pretty obvious.

as the topicstarter I think there's no denying now... :D

or is there....

Spaceface wrote:

kerrle wrote:

I think I just pretty much proved that the DS does antialiasing; I did what should have been the obvious thing.

I compared uncompressed, official screenshots of Mario 64 taken from the press kit, and enlarged areas that show antialiasing.

Below are links to three screenshots which have had sections enlarged, so that the effect can be easily seen. They're fairly big, as I didn't want compression artifacts to confuse people.

[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]

But I think you'll agree that it's pretty obvious.

as the topicstarter I think there's no denying now... :D

or is there....

Don't keep this going... :(
_________________
Little kids and Playstation 2's don't mix. :(

Hurrahs to everyone who believed!

I don't think anyone is denying that something is going on, just that it can't be AA in the true sense of the technique. I personally suggested sub-pixel trickery in the first post I made about this. It's certainly not traditional edge AA, its not FSAA.

Quite frankly, I don't see why the developers wouldn't apply it to all edges if it was available. The fact that it isn't applied to all edges, and that it appears to be applied at random (not strictly on near-horizontal or near-vertical) suggests that it's a side effect or some fortunate but uncontrollable process. To be honest with you, unless it was free I'd rather have it completely off and spend resources elsewhere than have some edges (that might not even be selectable) blended and some not, since it's barely noticeable and overshadowed by the lack of texture filtering, which affects a lot more pixels than triangle edges ever would.
_________________
outRider

Quote:

I don't think anyone is denying that something is going on, just that it can't be AA in the true sense of the technique. I personally suggested sub-pixel trickery in the first post I made about this. It's certainly not traditional edge AA, its not FSAA.

It absolutely is AA in the true sense of the technique. Antialiasing describes any technique for eliminating the visual aliasing caused by low sampling of an image. Whether it fits in with your idea of edge AA or full screen AA doesn't matter one bit. By your definition, the tile method used by the Dreamcast somehow isn't "proper" AA either, regardless of whether it produced a scene with less aliasing.

I don't understand why'd you'd even try to argue that this isn't "real" AA somehow; it's purely semantics. As far as why developers would use it - at this point, we don't know - it may be a hardware feature that is essentially "free". I agree that texture filtering would be a better feature to have than edge antialiasing, but as one is apparently available and the other is not, I don't really see the point of bringing it up.

EDIT:
All I'm really trying to say is that just because a method for AA isn't the one you know doesn't make it any less valid. Also, this is in no way "sub pixel trickery", at least in so much as relates to the color sub-pixels of the LCD.

The true sense of the technique (in my humble opinion) is that you render with the express purpose of reducing aliasing. It can't be a technique if it's a side effect, which is what I suspect it is, for reasons given previously. If you have any information that suggests that this AA is intentional and not some side effect of other processes, then please volunteer said information. Otherwise I'll stick to my opinion, thanks.

And I've already mentioned PowerVR's rendering method as equivalent to FSAA via supersampling. Please don't put words in my mouth.

And the point of bringing up texture filtering is that it's cheaper than edge AA. It makes it hard for me to believe that what you purport to be edge AA on the DS is possible, considering texture filtering is cheaper and easier, yet unsupported.

There's no need to take it personally.
_________________
outRider

I'm sorry, I just don't buy that it's a "side-effect". It's certainly not an effect of the LCD screen.

I fully grant that using traditional methods, antialiasing would be far too expensive, but in motion this is clearly more than just a by product - also, I can't think of any rendering process that could be reasonably capable of producting this result unintentionally, and I've personally written both span-based polygon engines and voxel engines. I'm not saying that it can't be so, just that, to me, this clearly looks like intentional antialiasing.

Using traditional methods, you're absolutely right in stating that texture filtering is less expensive than antialiasing. All I'm trying to point out is that, occasionally, some one figures out a new way to do things.

Both of you are taking it personally. Let's just agree something is happening, and it looks like AA. There's no point to bringing up texture filtering since it in no way effects AA. Is the AA intentional? That isn't the point here.

I personally am getting tired of this dead horse being flogged, so this is the last post I'll be making on this topic.

kerrle wrote:

I can't think of any rendering process that could be reasonably capable of producting this result unintentionally [...] I'm not saying that it can't be so, just that, to me, this clearly looks like intentional antialiasing.

That's the point, it might not be a typical rendering process: flicker and softening filters. Consoles use them, and since it is on the video signal output, it's not visible on a straight screen capture (I can't reproduce it on my Xbox with a framebuffer dump), it definitely blurs (some) contrasting edges, giving them a softer look. Considering there is no framebuffer on a DS, if screen captures come from the video signal any manipulation of that signal should be visible on the capture.

To paraphrase the relevent Xbox documentation, the filters are "TV encoder filters that remove some visual artifacts that are due to sharp color transitions."
_________________
outRider

I suppose that's possible, but generally filters like you're talking about can only be applied full screen, as they affect the color timing and other analog signal attributes, and can only be done once the image is finished and going through the DAC.

I really don't want to argue about it any more, but the edges which show smoothing really look like they were antialiased in a very standard way - they appear almost exactly as I'd expect from a supersampled or multisampled image. Note that I'm not suggesting that the DS is doing it either way, I'm just saying that if you actually look at the result on a DS and compare it to more standard antialias methods, the result is pretty much identical.

Look. According to the official DS hardware documentation from Nintendo, the DS can not do anti-aliasing (nor, for that matter, can it apply any sort of texture filtering). The fact of the matter is that you can make all of the harebrained claims you want, about how the third wall from your left if you go fifty paces northwest of the central save point and then turn right four times while standing on your head happens to be anti-aliased on its back-facing edges, but the fact of the matter is that you're full of crap and those of us with access to the appropriate information are sitting back and laughing at your ignorance.

Then look at the pictures I posted.

MooglyGuy wrote:

Look. According to the official DS hardware documentation from Nintendo, the DS can not do anti-aliasing (nor, for that matter, can it apply any sort of texture filtering). The fact of the matter is that you can make all of the harebrained claims you want, about how the third wall from your left if you go fifty paces northwest of the central save point and then turn right four times while standing on your head happens to be anti-aliased on its back-facing edges, but the fact of the matter is that you're full of crap and those of us with access to the appropriate information are sitting back and laughing at your ignorance.

We have only your word that you have access to the official documentation. This isn't much.

MooglyGuy wrote:

Look. According to the official DS hardware documentation from Nintendo, the DS can not do anti-aliasing (nor, for that matter, can it apply any sort of texture filtering). The fact of the matter is that you can make all of the harebrained claims you want, about how the third wall from your left if you go fifty paces northwest of the central save point and then turn right four times while standing on your head happens to be anti-aliased on its back-facing edges, but the fact of the matter is that you're full of crap and those of us with access to the appropriate information are sitting back and laughing at your ignorance.

I have heard otherwise.
_________________
~RiZeUp

MooglyGuy wrote:

Look. According to the official DS hardware documentation from Nintendo, the DS can not do anti-aliasing (nor, for that matter, can it apply any sort of texture filtering). The fact of the matter is that you can make all of the harebrained claims you want, about how the third wall from your left if you go fifty paces northwest of the central save point and then turn right four times while standing on your head happens to be anti-aliased on its back-facing edges, but the fact of the matter is that you're full of crap and those of us with access to the appropriate information are sitting back and laughing at your ignorance.

I'm am the "sitting back and laughing at your ignorance" right now, and it isn't hard at all to see the anti-aliasing, you'll see it in under a minute after you pop in your SM64DS in your DS, it's very noticable and easy to find, so I can't really see why people are still arguing that it isn't there.

Pfft. You're all a load of brainless fuckers. I'm just happy that I'll be going from my current employer to a $50k/yr job in six months, and you assholes will still be sitting around in mommy and daddy's basement, jerking off to the latest fucking homebrew Tetris game that you made because you can't get a real job. Pathetic.

And now we're supposed to believe that someone would hire YOU for $50k/yr?

Good one! Well, since you obviously don't need this forum since you've got the developer docs, maybe you should be banned? :)

MooglyGuy wrote:

Pfft. You're all a load of brainless fuckers. I'm just happy that I'll be going from my current employer to a $50k/yr job in six months, and you assholes will still be sitting around in mommy and daddy's basement, jerking off to the latest fucking homebrew Tetris game that you made because you can't get a real job. Pathetic.

Heh, who would've thought that anti-aliasing could spawn so much righteous indignation. Or have I just been trolled?

outRider wrote:

And the point of bringing up texture filtering is that it's cheaper than edge AA. It makes it hard for me to believe that what you purport to be edge AA on the DS is possible, considering texture filtering is cheaper and easier, yet unsupported.

I'm guessing that they left out texture-filtering to save on main memory bandwidth. Bilinear would quadruple texturing memory-accesses to 8 reads per pixel.

Quote:

Heh, who would've thought that anti-aliasing could spawn so much righteous indignation. Or have I just been trolled?

I once killed a guy who claimed that the DS could do antialiasing.

-Scott ;)

MooglyGuy wrote:

Pfft. You're all a load of brainless fuckers. I'm just happy that I'll be going from my current employer to a $50k/yr job in six months, and you assholes will still be sitting around in mommy and daddy's basement, jerking off to the latest fucking homebrew Tetris game that you made because you can't get a real job. Pathetic.

Wow, sporting salerys over internet forums, you are *sooooo* cool(and not at *all* pathetic).

Oh no, I've been trolled ;)

And Scott... That was my brother, I'll kill you bastard! Believe in DS antialiasing or DIE! ;P

Even the NES could do antialiasing of some sort. Look closely at one of Kirby's sprite cels in Kirby's Adventure; you'll see dark pink pixels filling in the corners of the outline. There are also a few subtle AA pixels in the Waddle Dee in front of Kirby. Of course, this isn't AA of vector edges, so it probably doesn't count, but wisely applied in-texture AA plus LCD blurring could reduce the need for texture filtering in some games.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

yea those pixels are obviously part of the sprite.

mike260 wrote:

outRider wrote:

And the point of bringing up texture filtering is that it's cheaper than edge AA. It makes it hard for me to believe that what you purport to be edge AA on the DS is possible, considering texture filtering is cheaper and easier, yet unsupported.

I'm guessing that they left out texture-filtering to save on main memory bandwidth. Bilinear would quadruple texturing memory-accesses to 8 reads per pixel.

Which also rules out any sort of FSAA as well.

Typical edge AA requires sorting per triangle per frame. That's orders of magnitude more expensive than extra memory reads. Not only that, but only silhuette edges can be antialiased, otherwise the scene will have cracks everywhere. Silhuette edge identification is expensive. I really can't imagine that the 3D core not only sorts triangles, but also identifies silhuette edges, every single frame. You have to remember that this is a handheld consumer device. If even your high end 3D hardware won't do it, is it reasonable to think that a DS, or even a PSP would do edge AA?

I've been sitting here the last hour getting paid for nothing, so I thought I'd try and guess at how the 3D core rendered, and here's what I came up with, if anyone wants to do some brainstorming.

Code:

list scanline_buffer[SCREEN_H];
list clipped_tris;
uint x_intercepts[SCREEN_H][2];

// transform all tris in the scene to screen space and clip against the screen

for (tri = 0 to *REG_TRIBUFFERSIZE - 1)
{
transform(tri);

if (!offscreen(tri))
   clipped_tris.add(tri);
}

// surviving triangles are in clipped_tris list
// sort surviving triangles front to back

if (hardware_sorting)
sort_tris(clipped_tris);

// determine for each triangle which scanlines it appears on and what its x intercepts are per scanline

for (tri = 0 to clipped_tris.size - 1)
{
uint min_y = min_vert_height(tri);
uint max_y = max_vert_height(tri);

scan_edges(tri, min_y, max_y, x_intercepts)

for (i = min_y to max_y)
   scanline_buffer[i].add(tri, x_intercepts[i]);
}

// for each scanline, draw all triangles that appear

for (scanline = 0 to SCREEN_H - 1)
{
uint x_ints[2];

clear_scanline();

if (hardware_sorting)
{
   // triangles are drawn front to back across each scanline from one x intercept to the other

   for (tri = 0 to scanline_buffer[scanline].num_tris)
   {
      // the first and last pixels on each scanline are triangle edges
      // but, not all triangle edges are also silhuette edges
      // silhuette edges are the only ones that can be antialiased against the background
      // if all edges are blended against the background cracks in the mesh will be visible

      putpixel_alpha(tri.x_ints[0], 127);

      for (pixel = tri.x_ints[0] + 1 to tri.x_ints[1] - 1);
            putpixel(pixel);

      putpixel_alpha(tri.x_ints[1], 127);
   }
}
else if (hardware_zbuffer)
{
   clear_zbuffer();

   for (tri = 0 to scanline_buffer[scanline].num_tris)
   {
      for (pixel = tri.x_ints[0] to tri.x_ints[1])
         if (pixel.z > zbuffer[pixel.x][scanline])
            putpixel(pixel);
   }
}
}

_________________
outRider

outRider wrote:

Typical edge AA requires sorting per triangle per frame. That's orders of magnitude more expensive than extra memory reads.

The PlayStation 1 could bin-sort triangles in hardware.

Quote:

Not only that, but only silhuette edges can be antialiased, otherwise the scene will have cracks everywhere. Silhuette edge identification is expensive.

Two words: Toon Table. Generating the darkened outline of a cel-shaded object involves somehow identifying the object's silhouette. This could be done by setting a "compute silhouette" flag after passing each mesh to the HW. Incidentally, giving the HW a signal between meshes could let the HW sort whole meshes and then sort tris within meshes, possibly making sorting more efficient.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Two words: Toon Table. Generating the darkened outline of a cel-shaded object involves somehow identifying the object's silhouette. This could be done by setting a "compute silhouette" flag after passing each mesh to the HW. Incidentally, giving the HW a signal between meshes could let the HW sort whole meshes and then sort tris within meshes, possibly making sorting more efficient.

Yeah, that was my idea but explained much, much better...
_________________
Shell Smash: 55730
Bounce and Trounce: 163

tepples wrote:

The PlayStation 1 could bin-sort triangles in hardware.

Your right, though it doesn't provide a perfectly sorted set but at the time it was cheaper than a having an associated zbuffer with the framebuffer. But if the DS uses a scanline zbuffer I don't see why they would want sorting as well. Having a small zbuffer with low latency memory would certainly work out to be much faster than computing average z per triangle for the purposes of depth sorting. I recall someone mentioning running into a wall in a game and observing correctly intersecting pixels, which suggests a zbuffer. Having perfect depth sorting via a zbuffer, is it really reasonable to assume that they would then add hardware sorting and silhouette detection just to get edge AA on probably less than 5% of the pixels on the screen?

Quote:

Two words: Toon Table. Generating the darkened outline of a cel-shaded object involves somehow identifying the object's silhouette. This could be done by setting a "compute silhouette" flag after passing each mesh to the HW. Incidentally, giving the HW a signal between meshes could let the HW sort whole meshes and then sort tris within meshes, possibly making sorting more efficient.

Toon shading isn't usually done with silhouette edge detection as such. Instead all backfacing triangles are drawn (switch the culling mode from CCW to CW or vice versa) in wireframe mode with thick lines, but thanks to the zbuffer nothing but the silhouette edge reaches the framebuffer. Identifying silhouette edges involves finding all edges shared by both a front-facing and back-facing triangle. It's even more expensive than z sorting.

Anyways, this is a sub $200 machine, with 2 screens, one being touch, and a wifi radio. Can they really afford to have a GPU that has a zbuffer, scanline intersects and z sorts triangles, and determines silhouette edges? I have no explanations for the pics posted previously, nor can I be sure that they are raw frame grabs, but in my honest opinion I seriously doubt that this machine as any sort of hardware support for any of the above. I'm much more inclined to believe that it's some other trick, such as jittering the scanlines, or some anomaly or side effect.
_________________
outRider

I agree with outRider's assessment. Toon shading is heavily expensive for even low-polygon models.
_________________
Rav (Win/Mac/Linux games for free)

As outrider said, drawing edges for toon rendering doesn't requires silhouette detection.

The way I know is almost similar to what he said, except instead of rendering in wireframe with thick lines, you render the backfaces of a shell (same model with vertices displaced along normals, can easily be precalculated) as polygons filled with an uniform color .

There's a least a game on PS1 that did toon shading, with silhouettes.

I don't know how they did implement the AA. I didn't find anything of note regarding how they pulled it off regarding polygon order. I just know it's there.
The 3d hardware of the DS is very unusual. It's seems it's been the product of out-of-box thinking, and that they have pulled some clever cheap way to do AA doesn't sounds too far fetched.

ravuya wrote:

I agree with outRider's assessment. Toon shading is heavily expensive for even low-polygon models.

And yet this is a built-in feature of the DS, and we have seen it running in real time with moderately good models. (http://media.ds.ign.com/media/682/682844/img_2139895.html they have video too, but this link was easy since I already posted it before)
_________________
Shell Smash: 55730
Bounce and Trounce: 163

MooglyGuy wrote:

Pfft. You're all a load of brainless fuckers. I'm just happy that I'll be going from my current employer to a $50k/yr job in six months, and you assholes will still be sitting around in mommy and daddy's basement, jerking off to the latest fucking homebrew Tetris game that you made because you can't get a real job. Pathetic.

Hmmm... You are what everybody with half a brain calls an idiot.

Who is your 'current empolyer' anyway?

Hungry Jacks?
Mcdonalds?
Red Rooster?

You aren't of any rellation to Moogle off IeXbeta, who stated that microsoft's developers have the ability to stop almost every bug in windows but arn't allowed to? (Which by the way, is impossible, as they can't test windows on every possible hardware configuration, or every possible software configuration, as they do have deadlines, and anyway, would beta testers that they have hired find every single bug? I doubt it.)

Don't worry, his $50K/yr job is probably plumbing or some other trade that will destroy his body and leave him up for future irrelevance.

By the way, I have an $80K/yr job in a nice cushy office. You might want to pass high school some time.
_________________
Rav (Win/Mac/Linux games for free)

ravuya wrote:

Don't worry, his $50K/yr job is probably plumbing

Don't forget that Nintendo's mascot put himself through medical school by being a plumber.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Well another cheap way to do toonshading is to use environmentmapping with a cellmap (eg a grey 128x128 texture with a thick-lined black circle touching the edges of the texture, and a white highlight in the middle of the texture).

Afaik the Nintendo 64 supported multitexturing, does anyone know if the DS can do that too? >> wishful thinking

bahnhof wrote:

Well another cheap way to do toonshading is to use environmentmapping with a cellmap (eg a grey 128x128 texture with a thick-lined black circle touching the edges of the texture, and a white highlight in the middle of the texture).

Afaik the Nintendo 64 supported multitexturing, does anyone know if the DS can do that too? >> wishful thinking

The N64 supported multi-texturing? I didn't know that.

It seems that Nintendo designs it's 3D hardware around the fact that many of it's games will get an extra boost by not using textures on 3D models but instead pure colors. Even on the Gamecube, it's clear that models don't use textures unless it's needed. Of course, 3rd party games go texture crazy, with textures everywhere they can be. Unfortunately, they end up looking bland and are often compressed beyond all belief.

Multi-texturing would be a nice effect on the DS, but with no filtering, I'm afraid the effect will decrease its quality instead of inceasing it.
_________________
Little kids and Playstation 2's don't mix. :(

I'm not sure I agree as far as the Gamecube goes, but yes, without texture filtering, I can't imagine that multitexture support would result in very good visuals.

The N64 had incredibly advanced multitexturing for its time. Too bad the texture memory was so ridiculously small that there wasn't much use for it..

Quote:

Even on the Gamecube, it's clear that models don't use textures unless it's needed

I thought GC could pull off the most textures of all current gen consoles...

ozfunghi wrote:

Quote:

Even on the Gamecube, it's clear that models don't use textures unless it's needed

I thought GC could pull off the most textures of all current gen consoles...

Sorry, I should clarify that more. In NINTENDO's first party games, that's the case. For example, Super Mario Sunshine, The Legend of Zelda: WW, Pikmin, Mario Power Tennis, etc...

2nd party games use more textures in their games, but not too much, like Star Fox Adventures, Metroid Prime 1 & 2, Eternal Darkness...

With 3rd party games, it's obvious that texture compression has lessened the quality in GCN games. It's especially easy to see when watching a CGI FMV on the Cube. For example, SSX Tricky's intro movie looks much cleaner on the PS2 than the GCN.

Take all these facts and apply them to the current situation: Super Mario 64 DS. Mario himself is only barely textured (probably the M on his cap is, nothing else) and the world around him seems to have more straightforward color. It's easy to notice if you go look at the Mario model in SSBM.

Then there are the 3rd party 3D games on the DS, Madden and Tiger Woods. Again, texture heavy, but they look weird because the system isn't a texture pumping machine... :(
_________________
Little kids and Playstation 2's don't mix. :(

dagamer34 wrote:

It seems that Nintendo designs it's 3D hardware around the fact that many of it's games will get an extra boost by not using textures on 3D models but instead pure colors. Even on the Gamecube, it's clear that models don't use textures unless it's needed.

Actually, texture-mapping has basically no performance impact on the Gamecube.

mike260 wrote:

dagamer34 wrote:

It seems that Nintendo designs it's 3D hardware around the fact that many of it's games will get an extra boost by not using textures on 3D models but instead pure colors. Even on the Gamecube, it's clear that models don't use textures unless it's needed.

Actually, texture-mapping has basically no performance impact on the Gamecube.

It's not the performance impact, it's the fact that the discs store less space than a standard DVD.
_________________
Little kids and Playstation 2's don't mix. :(

One day I will figure out how 1 gigabyte of data space is not enough for
developers today.

wombatman wrote:

One day I will figure out how 1 gigabyte of data space is not enough for
developers today.

High-resolution textures.
_________________
Little kids and Playstation 2's don't mix. :(

I know how big textures can get, but I think it's still enough space if its done properly. There are plenty of games that look fantastic on the Gamecube even with high quality textures.

I just got the chance to play RE4, and it honestly looks better than anything I've seen on any console, ever.

kerrle wrote:

I know how big textures can get, but I think it's still enough space if its done properly. There are plenty of games that look fantastic on the Gamecube even with high quality textures.

I just got the chance to play RE4, and it honestly looks better than anything I've seen on any console, ever.

I didn't say that all 3rd party games look bad. But in general, it's those multiplatform games from publishers that do well enough on the Gamecube to continue supporting it, but it seems not well enough to port it correctly using its strengths...
_________________
Little kids and Playstation 2's don't mix. :(

The top selling system is PS2 and because of this most developers start their game here but then when they port it to the next system to optimize profit they don't do any fix it work. Titles that are developed for this system from the start generally look great.
Ohh yea and I think I see some antialiasing in the nude peach scene on the ice level.

have anything been mentioned about overclocking the DS?

i know some people have said that the DS can't support a high level of AA, but when someone can hack the DS via the wi-fi or posible some other means (ds or gba ports) there is bound to be some minor altering of the DS's default programs: like picochat, and the main menu system. (i know i would like to see the warning screen removed, and have there be a way to get back to the main menu without turning the thing off first; but that it not really relevant at the moment) so, when someone does get the hacking down, eventually, wouldn't it be posible to add a bit of code, or program, that would OC the DS's cpu(s) or gpu clock speeds or memory? (sort of like on a computer, but i don't really know how simpliar the DS is to a modern computer, besides in preformance) for example, the cpu on my pda is a Xscale processor, it runs at about 400mhz, BUT the intel web site says it can run up to 1000mhz, only problem is battery life goes to hell. all i'm saying is would this be posible, OC the DS to get more power, and then add some more powerful AA code (thats if its software based) without loosing much due to the OC. just an idea. don't know about heat though...

Angry_Monk, the problem with that might be that the AA is entirly software controlled inside each game, thus you might have to hack each game to change it.

that would be a problem... oh well, even if that is the case i bet someone would do that if it doesn't take too much work and if the results are worth the effort. my idea was really only a way to get the DS to handle a higher amount of AA, as for setting the DS to a higher AA value i'm at a loss. none the less it is probably posible, maybe by altering the "drivers"/3d rendering code... but this is really not my area of knowledge.

i'm all for higher AA, some games could really use it.

Quote:

Ohh yea and I think I see some antialiasing in the nude peach scene on the ice level.

Peach, Nude, so should i be playing Mario 64 DS? Or is this a typo?
_________________
There Are No Stupid Questions, But There Are A Lot Of Inquisitive Idiots.

Joke, typo...you be the judge.

gbadev.org forum archive

DS development > Anti Aliasing on the DS

#32607 - Spaceface - Fri Dec 24, 2004 9:47 am

#32608 - Boeboe - Fri Dec 24, 2004 10:17 am

#32609 - mymateo - Fri Dec 24, 2004 10:24 am

#32615 - Spaceface - Fri Dec 24, 2004 11:28 am

#32617 - telamon - Fri Dec 24, 2004 11:40 am

#32619 - Spaceface - Fri Dec 24, 2004 12:12 pm

#32620 - mymateo - Fri Dec 24, 2004 12:12 pm

#32621 - mymateo - Fri Dec 24, 2004 12:15 pm

#32629 - Spaceface - Fri Dec 24, 2004 12:34 pm

#32634 - mymateo - Fri Dec 24, 2004 12:48 pm

#32638 - Sebbo - Fri Dec 24, 2004 1:33 pm

#32650 - mike260 - Fri Dec 24, 2004 4:26 pm

#32652 - ScottLininger - Fri Dec 24, 2004 4:46 pm

#32660 - abigsmurf - Fri Dec 24, 2004 5:46 pm

#32667 - manicdvln - Fri Dec 24, 2004 7:15 pm

#32675 - SmileyDude - Fri Dec 24, 2004 11:02 pm

#32677 - DrEggman - Fri Dec 24, 2004 11:34 pm

#32678 - mymateo - Fri Dec 24, 2004 11:38 pm

#32681 - EaDS Milliways - Sat Dec 25, 2004 12:24 am

#32683 - netdroid9 - Sat Dec 25, 2004 12:36 am

#32684 - ras - Sat Dec 25, 2004 12:36 am

#32694 - outRider - Sat Dec 25, 2004 3:39 am

#32707 - tepples - Sat Dec 25, 2004 5:21 am

#32720 - Sebbo - Sat Dec 25, 2004 8:41 am

#32722 - netdroid9 - Sat Dec 25, 2004 9:04 am

#32734 - ras - Sat Dec 25, 2004 1:32 pm

#32743 - arbitrary - Sat Dec 25, 2004 6:24 pm

#32746 - manicdvln - Sat Dec 25, 2004 6:41 pm

#32750 - xabib - Sat Dec 25, 2004 8:04 pm

#32753 - manicdvln - Sat Dec 25, 2004 8:26 pm

#32756 - ras - Sat Dec 25, 2004 11:18 pm

#32761 - Alex Atkin UK - Sat Dec 25, 2004 11:46 pm

#32765 - xabib - Mon Dec 27, 2004 2:33 pm

#32767 - Boeboe - Mon Dec 27, 2004 4:00 pm

#32771 - arbitrary - Mon Dec 27, 2004 5:32 pm

#32776 - kerrle - Mon Dec 27, 2004 7:31 pm

#32806 - DrEggman - Tue Dec 28, 2004 6:53 am

#32812 - Alex Atkin UK - Tue Dec 28, 2004 8:00 am

#32813 - mymateo - Tue Dec 28, 2004 8:07 am

#32816 - xabib - Tue Dec 28, 2004 11:04 am

#32823 - FluBBa - Tue Dec 28, 2004 2:03 pm

#32828 - Abscissa - Tue Dec 28, 2004 3:17 pm

#32831 - ector - Tue Dec 28, 2004 3:34 pm

#32883 - xabib - Tue Dec 28, 2004 11:33 pm

#32884 - mike260 - Tue Dec 28, 2004 11:38 pm

#32934 - xabib - Wed Dec 29, 2004 12:22 pm

#32953 - dagamer34 - Wed Dec 29, 2004 5:21 pm

#32959 - abigsmurf - Wed Dec 29, 2004 6:13 pm

#32974 - tepples - Wed Dec 29, 2004 7:10 pm

#32975 - zardozjones - Wed Dec 29, 2004 7:13 pm

#33024 - TJ - Thu Dec 30, 2004 6:15 am

#33068 - manicdvln - Thu Dec 30, 2004 5:25 pm

#33070 - NoMis - Thu Dec 30, 2004 5:32 pm

#33071 - ravuya - Thu Dec 30, 2004 5:34 pm

#33077 - Zlodo - Thu Dec 30, 2004 6:05 pm

#33082 - Alex Atkin UK - Thu Dec 30, 2004 6:15 pm

#33086 - Zlodo - Thu Dec 30, 2004 6:21 pm

#33103 - zardozjones - Thu Dec 30, 2004 8:32 pm

#33105 - Zlodo - Thu Dec 30, 2004 8:46 pm

#33111 - arbitrary - Thu Dec 30, 2004 10:19 pm

#33124 - xabib - Fri Dec 31, 2004 12:06 am

#33145 - Alex Atkin UK - Fri Dec 31, 2004 4:08 am

#33149 - Zlodo - Fri Dec 31, 2004 5:26 am

#33150 - outRider - Fri Dec 31, 2004 5:52 am

#33154 - tepples - Fri Dec 31, 2004 6:16 am

#33162 - kerrle - Fri Dec 31, 2004 7:04 am

#33167 - outRider - Fri Dec 31, 2004 8:26 am

#33171 - ravuya - Fri Dec 31, 2004 9:30 am

#33174 - arbitrary - Fri Dec 31, 2004 9:43 am

#33177 - Andor - Fri Dec 31, 2004 10:48 am

#33178 - ravuya - Fri Dec 31, 2004 10:57 am

#33179 - Kumba - Fri Dec 31, 2004 11:11 am

#33183 - arbitrary - Fri Dec 31, 2004 12:59 pm

#33186 - Zlodo - Fri Dec 31, 2004 1:54 pm

#33241 - DrEggman - Sat Jan 01, 2005 12:39 am

#33245 - Gatchers - Sat Jan 01, 2005 1:26 am

#33281 - Zlodo - Sat Jan 01, 2005 3:32 pm

#33288 - tepples - Sat Jan 01, 2005 5:27 pm