gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Missing 3D features

#106404 - M3d10n - Wed Oct 18, 2006 6:47 pm

There are two things I noticed that aren't documented in the homebrew dev scene yet.

First is the shadow volumes stuff. A bunch 3D DS games use them (Mario 64 and Mario Kart are the most obvious ones), and it seems to work much like the Dreamcast's implementation (simple geometry which darkens pixels inside them). Are the registers which control this feature still unknown?

And second, about framerate. I know you can only draw so many polygons on a frame, and that you need to use the display capture to do accumulative drawing. But what happens when the game misses a v-blank, due to high CPU usage, as example? Commercial games seem capable of dropping frames when needed, the infamous Mario 64 DS cap duplication bug being a prime example. Can we do the same with the homebrew libs?

#106407 - Dark Knight ez - Wed Oct 18, 2006 7:15 pm

Quote:
But what happens when the game misses a v-blank, due to high CPU usage, as example?

The previous drawn 3D frame remains on screen until you've drawn the next. AmplituDS runs at 30 FPS currently and no flickering is perceived. When it dropped to 15 FPS (due to missing a vblank, now not an issue anymore) it still did not have flickering of any kind.

#106410 - M3d10n - Wed Oct 18, 2006 7:47 pm

Nice, can the DS do the same with sprites and tiles?

#106412 - Dark Knight ez - Wed Oct 18, 2006 7:58 pm

That follows a similiar approach.
You can work with data items, but only when you copy them to the places where the DS expects them to be (similiar to glFlush as in: only then the actual update takes place) will the screen be affected.
This copying should be done after a vblank to avoid this being done while the screen is being rendered.

#106422 - ecurtz - Wed Oct 18, 2006 9:24 pm

M3d10n wrote:
First is the shadow volumes stuff. A bunch 3D DS games use them (Mario 64 and Mario Kart are the most obvious ones), and it seems to work much like the Dreamcast's implementation (simple geometry which darkens pixels inside them). Are the registers which control this feature still unknown?


gbatek has this to say about shadows (Polygon Mode == 3), I haven't tried it at all, but it's a good place to start:

40004A4h - Cmd 29h - POLYGON_ATTR - Set Polygon Attributes (W)
0-3 Light 0..3 Enable Flags (each bit: 0=Disable, 1=Enable)
4-5 Polygon Mode (0=Modulation,1=Decal,2=Toon/Highlight Shading,3=Shadow)
6 Polygon Back Surface (0=Hide, 1=Render) ;Line-segments are always
7 Polygon Front Surface (0=Hide, 1=Render) ;rendered (no front/back)
8-10 Not used
11 Depth-value for Translucent Polygons (0=Keep Old, 1=Set New Depth)
12 Far-plane intersecting polygons (0=Hide, 1=Render/clipped)
13 1-Dot polygons behind DISP_1DOT_DEPTH (0=Hide, 1=Render)
14 Depth Test, Draw Pixels with Depth (0=Less, 1=Equal) (usually 0)
15 Fog Enable (0=Disable, 1=Enable)
16-20 Alpha (0=Wire-Frame, 1..30=Translucent, 31=Solid)
21-23 Not used
24-29 Polygon ID (00h..3Fh, used for translucent, shadow, and edge-marking)
30-31 Not used


Writes to POLYGON_ATTR have no effect until next BEGIN_VTXS command.
Changes to the Light bits have no effect until lighting is re-calculated by Normal command. The interior of Wire-frame polygons is transparent (Alpha=0), and only the lines at the polygon edges are rendered, using a fixed Alpha value of 31.

#106466 - M3d10n - Thu Oct 19, 2006 12:17 pm

Awesome info, thank!