10th March 2005, 12:10 PM
Dark Jaguar Wrote:Basically the only thing that would need be done is split it up via software and have one processor responsible for this part of the screen and another responsible for the other side.
That cannot be done, since you're actually splitting the screen you are not creating an independent source for the graphics. You can use 2 CPUs while splitting the screen, but it wont use one on each 'side' of the screen. It will kick each CPU depending on what is needed for both sides of the screen. If there's an explosion on the left side, both CPU's will render it. They'll act like one, larger CPU. Hence the whole "64 bit Dreamcast" argument. If you split via software YOU ARE WASTING CPU RESOURCES.
Quote:I'm pretty sure that could be done using a VERY small amount of processing power, the amount needed for, like, SMB3's menu screen being seperate and not scrolling and the actual level being able to do all manner of things without it above. And besides, the system already needs to determine which processor is responsible for what, and in the case of dividing up the screens, which one sends it's finished image to what screen.
1.) One larger split screen takes TWICE THE CPU's POWER TO RUN.
2.) I'm not talking about an overlayed menu, i'm talking about an entire game. With physics, animations, a game engine. A menu is not a game engine. It is a menu overlay.
3.) The CPU's do not decide what image to send to what screen. That is done through software, the software must tell each CPU what to do so that they can act independently.
Stylus programing is easy on a touch screen. You just use the guidepoints on the screen and the Stylus will act as a reference. But using a stylus for gameplay adds an entire deminsion to the programing which now includes animations, physics and the game engine itself. Now, your guidepoints have to include the weight of a ball, the spin, the velcocity, etc. That is not easy to program.
Yes, both CPU's can handle the same amount of work, that is how they can act independent. And that is why you can have two game engines running simultaneously with fluidity through hardware, not software. In other words, on the DS, you can simply slap two game engines in to it instead of having to create a single game engine that can run both engines. Which means more R&D and more money.
Touch screens are incredibly expensive. Just the lower touch screen on the DS costs as much to manufacture as the entire PSP screen. The reason touch screens are so expensive is because it's not just a screen, it actually has a completely different methodology.
The entire point of the DS is to have two screens that can display whatever the designers want independently without hindering the other CPU while one of the screens offers touch. A split screen game cannot show, for example, a 3-D fighting game on one side with a 2-D puzzle game on the other without draining the CPU(s) drastically since they'll act as one and try to render everything on the entire screen.
If you think the examples above can be done on one screen, show me how it would be done.
I talk to game designers constantly and I get to talk to R&D and testers for companies like EA and Sega and I get all my info from them. It's great that you know some programing but i'll take my chances with the info from the people who actually program for the DS.