#126177 - Mifheu - Fri Apr 20, 2007 5:56 pm
I'am currently in the planning stage for a DS game and I'd like to know, if the DS can really draw ~4000 polys when the game is running at 30fps. I searched around the net and got lots of different informations. As far as I know, the DS can render ~2048 polys/6144 verts at 60fps depending on the kind your mesh is build (polystrips/quads and so on). But I also heard, it is possible to double the polycount to 4096 polys by dropping the framerate to 30fps and use some tricks.
I'd really like to know, if this is true, because I want the right informations for my concept and my prototype graphics, so I can do right planning for the graphics and the stages. And of course it would be bad to tell bullsh.t to potential publishers in the fist place. :)
Can anyone clarify this? Thanx!
_________________
Simplicity is the most complex topic.
#126187 - dovoto - Fri Apr 20, 2007 7:36 pm
You cannot really increase the poly count by droping the frame rate as the DS only has enough room in its vertex buffers for 2048 triangles.
What you can do however is to render a frame and capture it to vram then render another frame on top. With careful compositing you can effectivly get twice the polies. For instance you could render the terain in one pass and the objects in another for an outdoor scene.
_________________
www.drunkencoders.com
#126190 - Mifheu - Fri Apr 20, 2007 7:52 pm
Thanx alot.
Just a few hours later I found a description on how to "increase" the polycount. May just work for my concept. On the other hand, as far as I understand this technique, it means you lose a memorybank, which is not so nice ;-)
_________________
Simplicity is the most complex topic.
#126212 - Dood77 - Sat Apr 21, 2007 1:04 am
| dovoto wrote: |
| What you can do however is to render a frame and capture it to vram then render another frame on top. With careful compositing you can effectivly get twice the polies. For instance you could render the terain in one pass and the objects in another for an outdoor scene. |
Heh, so you're effectively running at 60fps, but using every other frame for graphics enhancements and holding them back a frame, so really its 30fps...?
#126223 - M3d10n - Sat Apr 21, 2007 2:35 am
| dovoto wrote: |
| What you can do however is to render a frame and capture it to vram then render another frame on top. With careful compositing you can effectivly get twice the polies. For instance you could render the terain in one pass and the objects in another for an outdoor scene. |
But there's no way to preserve the depth buffer between each pass, is there?
If not, wouldn't it be safer and easier to change the near and far clipping planes in each pass and split the scene in distant/nearby geometry? It would generate a few more polygons due to the clipping, though.
#126272 - 3D_geek - Sat Apr 21, 2007 4:07 pm
| Quote: |
| But there's no way to preserve the depth buffer between each pass, is there? |
No - I'm pretty sure the NDS doesn't even have a depth buffer in the conventional sense.
| Quote: |
| If not, wouldn't it be safer and easier to change the near and far clipping planes in each pass and split the scene in distant/nearby geometry? It would generate a few more polygons due to the clipping, though. |
I'm not sure whether it clips before or after the 2048 triangle buffer - if it's before then what you propose is a really good way to go - it it's after then you're still screwed.
But either way, the worst problem (in a very dynamic game) is knowing where to split the Z depth to ensure that no part of the scene blows the limit - without range-sorting, you can't ever know.
#126273 - tepples - Sat Apr 21, 2007 5:02 pm
If you can sort most of your geometry before sending it to the GTE, you can split it into a back frame and a front frame, and nobody will notice slight coverage errors at the "crack" between the two passes. For instance, in a game like Animal Crossing: Wild World, where the camera is always at the south, you can draw the north half of the visible acre in one frame and the south half in the next.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126296 - LiraNuna - Sat Apr 21, 2007 10:46 pm
| Quote: |
| You cannot really increase the poly count by droping the frame rate as the DS only has enough room in its vertex buffers for 2048 triangles. |
2048 triangles? the GBA's ARM7 can draw more then that with it's eyes closed and hands behind it's back. Just check kusma's _amazing_ engine (shift faced clowns).
Just look at their (his?) engine growing, doing much better then the DS's HW 3D.
/me looks at the DS's box, which says something about 'stunning' 3D graphics
</rant>
_________________
Private property.
Violators will be shot, survivors will be shot again.
Last edited by LiraNuna on Sun Apr 22, 2007 11:55 am; edited 1 time in total
#126298 - 3D_geek - Sun Apr 22, 2007 12:41 am
That's a REALLY outrageous claim...and it can't go unanswered.
The NDS's 3D processor can draw 2048 large-area, depth-sorted, textured, fogged, alpha-blended, transformed and lit (with four coloured light sources) triangles at 60Hz frame rates.
With the ARM7, you have a 33MHz clock - at 2048 triangles and 60Hz, that's 268 CPU clock cycles per triangle - perhaps just barely enough for a minimal rotate/translate/perspect/clip/light providing vertices are shared between triangles efficiently. But you've also got to fill the pixels - and at 256x192 pixels resolution and 60 Hz frame rate (which the 3D processor maintains very solidly), you have a whole 11 clock cycles per pixel - and that's assuming you are using zero time for your per-vertex operations...which you are most certainly not! That's not enough to do even one true perspective texture lookup - let alone fogging, blending, edge antialiasing and all of the other things the NDS's 3D processor can do at pixel rates - and that;s assuming you only have one layer of pixels covering the screen - with is a completely unreasonable thing.
You may be able to find some suitably crippled 3D rendering mode that'll get you 2048 triangles at 60 frames per second - but not with all of the bells and whistles you need for serious 3D gaming.
So please - lets have none of these outrageous claims. You can't possibly come even close to doing 2048 "usefully rendered" 3D triangles at 60Hz on the ARM7 - you can do that quite easily on the ARM9+3D-copro - end of story.
Geez - do you really think Nintendo would have gone to all of that development expense if the new machine was spec'ed no better than a GBA?
Get real.
#126310 - tepples - Sun Apr 22, 2007 2:39 am
The Shitfaced Clowns demos, such as Newton and FFD, run at about 12 fps. In fact, they overclock the GBA ROM to 2/1 wait to do it. That's why they also come in a patched version for F2A and other slower GBA cards that only support 3/1, and why they don't stand a chance of running on a SuperCard.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126319 - DekuTree64 - Sun Apr 22, 2007 5:16 am
It would be interesting to see a game that runs more or less entirely on ARM7, using ARM9 as a software rendering powerhouse. That way you get cache for textures, and "free" division.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#126329 - kusma - Sun Apr 22, 2007 11:13 am
The Shitfaced Clowns engine does not run anywhere near 2048 polys at 60 fps. It's a pretty basic scan-converting 3d engine with some neat hacks (like anti aliasing). On the DS you have three processors running in parallel, and not using one of them would be plain stupid. So, while you'll most likely have to live with the 2048-poly limit, you can spend the free cpu cycles on other useful things.
edit: Also keep in mind that this is 2048 visible polygons. That's actually quite a lot.
#126355 - tepples - Sun Apr 22, 2007 4:17 pm
So if you include polygons that face away from the camera in your scene's triangle count, the limit does come closer to 4096 triangles. You can inflate this further if you can find quads, or pairs of triangles that share a side and have coplanar vertices. A quad takes up 4/3 of the space of a triangle in vertex RAM, compared to the equivalent triangles that take up 2 triangles.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126367 - silent_code - Sun Apr 22, 2007 6:04 pm
| Mifheu wrote: |
| Just a few hours later I found a description on how to "increase" the polycount. |
so, where did you find it? share the information with us. ;^)
#126373 - HyperHacker - Sun Apr 22, 2007 6:53 pm
Keep in mind too: you could use that nice CPU power on the ARM7 and ARM9 to do software rendering while simultaneously doing hardware rendering with the GPU. kusma said it best: you have 3 processors, why ignore one?
_________________
I'm a PSP hacker now, but I still <3 DS.
#126378 - tepples - Sun Apr 22, 2007 7:09 pm
Hardware and software rendered objects cannot occlude each other. You can have a software background, a hardware middle, and a software foreground, but you can't have software-rendered objects in the middle of hardware-rendered objects.
Another thing you can do is use the 3D hardware to render with capture and, in the next frame, display the captured textures as sprites using the 2D core. This sort of resembles the way Tony Hawk's Pro Skater games for GBA worked. If you do it right, you might not lose overall 60fps even if you do lose 60fps for individual sprites.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126385 - HyperHacker - Sun Apr 22, 2007 7:33 pm
| tepples wrote: |
| Hardware and software rendered objects cannot occlude each other. You can have a software background, a hardware middle, and a software foreground, but you can't have software-rendered objects in the middle of hardware-rendered objects. |
No, but you could e.g. software-render parts of your scene as a texture, using one hardware polygon to display a number of software polygons. It all really depends on your scene what can be done.
_________________
I'm a PSP hacker now, but I still <3 DS.
#126386 - kusma - Sun Apr 22, 2007 7:34 pm
or how about doing texture-space effects on the ARM9 for the next GPU frame?
#126509 - M3d10n - Mon Apr 23, 2007 11:09 pm
Tepples, maybe you could use a software renderer to draw impostors for distant objects and maybe even characters, and then mix those with the actual HW 3D stuff using screen aligned quads?
Such objects will require little fillrate due to the small rendered region, but would consume valuable polygons if rendered using the 3D hardware.
Actually I suspect that Dragon Quest Monster game already does that.
#126512 - tepples - Tue Apr 24, 2007 12:14 am
| M3d10n wrote: |
Tepples, maybe you could use a software renderer to draw impostors for distant objects and maybe even characters, and then mix those with the actual HW 3D stuff using screen aligned quads?
Such objects will require little fillrate due to the small rendered region, but would consume valuable polygons if rendered using the 3D hardware.
Actually I suspect that Dragon Quest Monster game already does that. |
So does Animal Crossing.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126956 - Marcel24 - Sat Apr 28, 2007 12:27 pm
Hi,
maybe we can get over the 2048 poly limit..
We have 6144 vertex ram for 2048 polys.
What happends if we use TRIANGLE_STRIPS for saving some vertex's ?
can we then go throw the limit ?
just a thought..
cya
#126958 - tepples - Sat Apr 28, 2007 1:57 pm
There's also a limitation on polygon RAM, and triangle strips won't help you much with that. If you use quad strips, you can break that. For instance, a 24-sided ball can be drawn as six strips.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#126970 - gabebear - Sat Apr 28, 2007 4:16 pm
I've not played with it, but you can pre-load the depth buffer each frame.
http://nocash.emubase.de/gbatek.htm#ds3drearplane
Which should make it possible to have software and hardware rendered 3D objects occlude each other. I haven't seen anyone use this feature, but it could be used to make some really neat effects.
Too bad there doesn't seem to be any way to read out the depth buffer...
#127724 - silent_code - Fri May 04, 2007 9:37 am
but that costs you a whole vbank... and i don't remember if you then *had* to use the bg image too (like forced to use it), which also requires a whole vbank.