A) Makes more sense, but unless it's moving, I still don''t see how it's be more efficient than a sprite.
B) There was a reason I decided that information was insufficient when I skimmed it, but I can't remember any of it anymore. I'll try to remember to come back to it and ask a more specific set of questions later.
AnyOldName3 Wrote:A) Makes more sense, but unless it's moving, I still don''t see how it's be more efficient than a sprite.
Ugh, you have any idea how games work.
some more Doom 3 mapping with a Minecraft themed map and a shader for the tree leaves
(04-16-2014, 10:27 AM)AnyOldName3 Wrote: [ -> ]A) Makes more sense, but unless it's moving, I still don''t see how it's be more efficient than a sprite.
She's an idol on a stage. Of course she's gonna move around. And no shit they wouldn't pack sprites that big onto a tiny DS cart.
Doom 3 rendered at 256 × 192 (DS Resolution)
Gir: Looks dramatically better than the average DS game, but still doesn't beat the difference from whatever that idol game is.
(04-16-2014, 10:51 AM)pauldacheez Wrote: [ -> ] (04-16-2014, 10:27 AM)AnyOldName3 Wrote: [ -> ]A) Makes more sense, but unless it's moving, I still don''t see how it's be more efficient than a sprite.
She's an idol on a stage. Of course she's gonna move around. And no shit they wouldn't pack sprites that big onto a tiny DS cart.
Fwiw, paletted pixel data is really quite compressed, and you can in a lot of cases use less bytes than as many pixels as the sprite actually needs. E.g. a 16 color palette basically lets you represent 2 pixels per byte (each nibble represents a value of 0-15, which gets translated into a color by the palette. A 32 color palette lets you represent 8 pixels in 5 bytes. So the amount of space it takes to draw large sprites isn't really that much.
What is a concern is the copy process to get that data into VRAM. I think Nintendo handhelds prefer DMAs for this since making your own ARM code to do this eats up ROM space (THUMB mode ain't so bad) and eats up cycles that the CPU could otherwise be doing something important. Add to the fact that animating such large sprites costs even more ARM code and cycles (and effort on the programmer's part), 3D models are the way to go. If you can tell the DS to change a few vertices in one frame, then have it automatically render and rasterize that to the screen, you're going to do that instead of having ungainly code to animate a single large sprite (or even a meta sprite comprised of numerous lesser sprites, which sounds like a coding nightmare to pull off in real-time, though scripting it was done frequently enough in many games).
You could make everything a sprite that would normally have been a 3D model (see Rare's pre-N64 Donkey Kong games, all of them) but why would you want to?
Yeah, DMA vs. manual copy code has nothing to do with eating up ROM space really. A loop that copies data is probably shorter than code that sets up a DMA copy. It's all about speed of transfers and the fact that DMA transfers are async.
(04-16-2014, 02:18 PM)Shonumi Wrote: [ -> ] (04-16-2014, 10:51 AM)pauldacheez Wrote: [ -> ] (04-16-2014, 10:27 AM)AnyOldName3 Wrote: [ -> ]A) Makes more sense, but unless it's moving, I still don''t see how it's be more efficient than a sprite.
She's an idol on a stage. Of course she's gonna move around. And no shit they wouldn't pack sprites that big onto a tiny DS cart.
Fwiw, paletted pixel data is really quite compressed, and you can in a lot of cases use less bytes than as many pixels as the sprite actually needs. E.g. a 16 color palette basically lets you represent 2 pixels per byte (each nibble represents a value of 0-15, which gets translated into a color by the palette. A 32 color palette lets you represent 8 pixels in 5 bytes. So the amount of space it takes to draw large sprites isn't really that much.
What is a concern is the copy process to get that data into VRAM. I think Nintendo handhelds prefer DMAs for this since making your own ARM code to do this eats up ROM space (THUMB mode ain't so bad) and eats up cycles that the CPU could otherwise be doing something important. Add to the fact that animating such large sprites costs even more ARM code and cycles (and effort on the programmer's part), 3D models are the way to go. If you can tell the DS to change a few vertices in one frame, then have it automatically render and rasterize that to the screen, you're going to do that instead of having ungainly code to animate a single large sprite (or even a meta sprite comprised of numerous lesser sprites, which sounds like a coding nightmare to pull off in real-time, though scripting it was done frequently enough in many games).
You could make everything a sprite that would normally have been a 3D model (see Rare's pre-N64 Donkey Kong games, all of them) but why would you want to?
My main surprise was that as far as I can remember, all of my DS games have about 12 polygons (I remember noticing in one game (and not an obscure game, but something reasonably popular) a sphere was actually a phong-shaded triangle-based pyramid, even though it took up a large amount of the screen in many circumstances), so it looked like that single model was higher poly than entire rooms in some games.
Your games must have looked like poop :p
The DS allots enough RAM to keep track of a maximum of 2048 polygons composed of a maximum of 6144 vertices altogether.