9th March 2005, 2:22 PM
Yeah, that's good thinking... I mean, the two screens are still bigger than the GBA screens, so like, was that really cheaper? They still had to make a new type, just not as big... hmm probably... I am pretty sure that only having half the screen space be a touch screen saved some money...
OH! I just realized that, well, have you noticed that the non-touch screen has a clearer image because the touch layer isn't sorta blurring the light? Not anything major, but somewhat clearer? That may have been a small part of their choice...
And oh yes, actually the two screens aren't a totally invisible thing. The code still needs to determine what part of the image is going to what screen (okay, this is on the top, this is on the bottom), but that's a last step thing, done after everything else, so again it doesn't really matter.
This is just making my point a bit clearer to lazy: Those two processors having dedicated tasks is nice and all, there's a reasons duel processing is done outside of DSs after all, and having two different graphics engines dedicated to a specific processor will speed things up, but that's not actually needed for the screens. It's probably the better way to do things, but not needed. In the reverse, as I said, even with two screens rendering two images, being assigned to two seperate screens is not required at all. It looks a lot better TO assign each one to an individual screen, but they could easily, for example, have just half of one screen use the 3D processing while the other half and the entire other screen is doing the 2D, or my other examlpe of the left half of both having 2D and the right half of both doing 3D. Also, dividing it up like that is needed in the context of there being only one touch sensitive screen... Well actually, what if a game is made where both the 2D and the 3D stuff has touch parts? Maybe in a few it might actually be needed to partition it as I described?
More than that though, they could just do 3D on both screens at once. Due to the larger area, the maximum poly and texture count would have to take into account all the stuff that could be shown at once using this, thus limiting it a bit, but it could be done, and in fact, it is done in a few of the minigames in Mario 64 DS (specifically, the ones where a bunch of Marios are flying around both screens at once).
OH! I just realized that, well, have you noticed that the non-touch screen has a clearer image because the touch layer isn't sorta blurring the light? Not anything major, but somewhat clearer? That may have been a small part of their choice...
And oh yes, actually the two screens aren't a totally invisible thing. The code still needs to determine what part of the image is going to what screen (okay, this is on the top, this is on the bottom), but that's a last step thing, done after everything else, so again it doesn't really matter.
This is just making my point a bit clearer to lazy: Those two processors having dedicated tasks is nice and all, there's a reasons duel processing is done outside of DSs after all, and having two different graphics engines dedicated to a specific processor will speed things up, but that's not actually needed for the screens. It's probably the better way to do things, but not needed. In the reverse, as I said, even with two screens rendering two images, being assigned to two seperate screens is not required at all. It looks a lot better TO assign each one to an individual screen, but they could easily, for example, have just half of one screen use the 3D processing while the other half and the entire other screen is doing the 2D, or my other examlpe of the left half of both having 2D and the right half of both doing 3D. Also, dividing it up like that is needed in the context of there being only one touch sensitive screen... Well actually, what if a game is made where both the 2D and the 3D stuff has touch parts? Maybe in a few it might actually be needed to partition it as I described?
More than that though, they could just do 3D on both screens at once. Due to the larger area, the maximum poly and texture count would have to take into account all the stuff that could be shown at once using this, thus limiting it a bit, but it could be done, and in fact, it is done in a few of the minigames in Mario 64 DS (specifically, the ones where a bunch of Marios are flying around both screens at once).
"On two occasions, I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question." ~ Charles Babbage (1791-1871)