Maybe you have a level with pipes, where you could go down one (onto the small screen) and then fly up through another to ambush your opponent. Or how about a super secret item, like a mystery box from Mario Kart, that would display on the bottom screen so YOU know what you're holding, but no one else does? Do you have a banana or a blue shell?! Ooo, the tension!
Or at the very least you could tap the touch screen to trip. That's a useful feature, right?
@-JKR- I can't tell how serious you are, but the battle mode in 4 Swords was freaking awesome, in part because you could go off the main screen and mess around with switches and yada yada that affected the rest of the course. Not that I'd want every Smash stage to have this, but if a few did...?
Actually 4 Swords battle mode reminded me a lot of Smash.
Nintendo has never released a Mario console game and a Zelda console game in the same year (as far as I remember), let alone two systems the same year. Would make zero sense. If you think it's coming this year, you're ignoring logic for your own fantasies and setting yourself up for disappointment.
GBA - June 11th, 2001 (N.America) Gamecube - November 18th, 2001 (N.America)
Not saying it's going to happen, just saying that is has before and it's possible again.
I feel like past systems required less of an investment though... well, they did require less of an investment. And the economy was better back then as well. I think pushing out a $250 handheld and then a $300-$400? console in the same year in 2011 isn't quite the same as charging $100? for a handheld and $200 for a console back in 2001. I know, inflation and all, but that's a minor thing next to the changed economic landscape... not to mention there hasn't been that much inflation, we're talking prices that are nearly or more than double what they used to be in a mere 10 year span.
Yea, that's true, there could definitely be some sweet uses for it. I was thinking more along the lines of the core gameplay, but maybe you could have to draw a shape on the touch screen to pull off your power smash, like in one of those DS Castlevanias. Still, I think there are lots of games that will benefit more clearly from this than Smash.
- Input delay from Compression/Encoding/Decoding of the video
Not to mention the degradation of image quality due to compression. It doesn't matter how good the compression techniques are, the console isn't powered by magic and compressing/encoding/decoding of any video is going to take time and cause a noticeable delay between when the player makes an input and when we see the video on the controller screen. Surely Nintendo of all game companies would find this unacceptable.
How can you not see the benefit of the console not needing to go through that conversion process? And you're acting like streaming data to the controller is going to require a completely different engine than the normal engine. At most, it's going to require a different set of instructions/commands/protocols, but an engine does that normally anyway. I'm referring to the final frame of the game being rendered off-screen, and then RASTERIZED on the controller itself. Even though it would use up more bandwidth, it would be nothing compared to converting the data to video in real-time to be streamed. Eliminating the conversion process is a clear advantage for streaming interactive data to a remote device.
Most solutions don't use this method because video streaming is designed to be flexible with many different devices. But there is an advantage of streaming to a device specialized for the console. You don't have to worry about compatibility since you can install the corresponding components to make the streaming more efficient (like using an external framebuffer) in the controller specialized for the console.
@Jargon I also said I'd be shocked if it wasn't real and I am. I like, still believe it is real haha. I'm not one of those obsessive ON people (hey I never believed On for a second and I thought people who did were shitsilly) but....I am actually surprised that wasn't the real deal.
And yes I have learned a lesson cuz I've now decided not to freak out if Wii 2 is 2 Wiis duct taped together. I'll be pissed, but I decided I won't make a big deal about it. I'll quietly and calmly express my extreme disappointment and that'll be that.
Regarding the images being faked though I'm surprised but not too bummed out cuz it could still look close to that, if not better. If it ends up looking like dogshit it'll be like "Nintendo shoulda hired that man!". For the record I was in love with the console design while the controllers were okay.
According to the French site, it looks like the console will actually be streaming data, NOT video, which makes sense because I could not imagine Nintendo being satisfied with the performance of normal video streaming. The streaming they purport the console to use is being referred to as virtualization (though there are different methods of virtualization as far as I know).
The console and the controllers could operate on a principle of "virtualization," the bulk of the calculations performed by the console itself, and controllers serving terminals capable of displaying the code pre-calculated. Ce système permettrait de diffuser du jeu en haute qualité sur les manettes, sans latence notable et sans passer par un flux vidéo compressé et exigeant en termes de bande passante. This system would distribute the game in high-quality controllers, without significant latency and without using a compressed video stream and demanding in terms of bandwidth.
If they go this route, it will be a near perfect solution with hardly any drawbacks.
It's a tiny screen so I don't see image degradation being a huge issue. Conversion to a "video" and compression may or may not happen, but if so then encoding can be done in real time. I'm not sold as this notion being the right way, but I'm not sold on how I'm understanding your method either.
Bandwidth is the issue I had in mind the entire time, and you just said something which I thought would happen with your method: It would require more bandwidth and there could be penalty for splitting up the graphics pipeline over wireless. Seems like the console can just rasterize the image itself and send that rendered frame via wireless signal to the controller. Unless we're both talking about the same thing now?
Frames and video are also data. That site sounds like it's speculating the same thing you are. They don't seem to hint they know how it really works. Their description is a bit vague, maybe it was lost in translation. I will want to hear more about this, though.
It's something called an Ultra Thin Client. Basically, when a console has finished all of its internal graphics processing, it is sent to a raster op (to change the data from vectors to actual pixels), then to the framebuffer (an amount of video memory that buffers the next frame of scene to be sent out to the display) , and finally output to the display controller (which subsequently outputs to your tv).
With most video streams, the end device only needs a display controller to display the video stream on its screen, but the video has to be encoded and decoded, and then compressed, in real-time. Since you cannot directly interact with the video, the console has to wait to receive input from you before it can update the stream, starting the conversion process of encoding/decoding/compressing all over again. This process causes a significant delay between the input of the controller, and what's being displayed on the screen. Stuff like touch screen input would be completely broken (you expect whatever you touch on the screen to respond instantaneously).
With an Ultra Thin Client, the end device is like an extension of what's already inside the console, so there is no need to stream a video to it, as it can output the raw data itself. Using this method allows for instantaneous interactivity with what's being displayed on screen, and also saves the console a little processing power.
But you need to pull texture information from the graphics memory after/during rasterization? So now the controller will ideally need enough memory to store (buffer) the textures, because I assume there is a huge penalty for needing those textures in realtime and being limited by wireless bandwidth.
So are we on the same page now? I see that's how it would work, and work the best out of any solution, if the controller indeed had the hardware to pull it off. The question now is benefit vs. cost.
Also filtering methods would require the controller to have an even beefier processor, yes? Those come after rasterization. Although, it's probably not a big deal on such a small screen.
Yes, that's what I'm suggesting (fetching the texture data during the rasterization process). If it's truly an Ultra Thin Client, then it'll have the proper hardware. Also, a modest ARM processor would be pretty cheap and would be enough to handle a lot of post-processing. It doesn't need to render games, so we're not looking at anything too expensive.
One thing I forgot to mention was that the Wii 2 will only have so many ROPs (Raster Operations Pipelines), so that's another other benefit to using the controllers as Ultra Thin Clients. Essentially, if every controller had its own ROP, then the amount of controllers connected wouldn't be limited to the amount of ROP's included in the console's GPU.