View Full Version: Stereo 3D

fuzziqer >>GameCube Action Replay Simulator and Control Simulator >>Stereo 3D


<< Prev | Next >>

biolizard89- 03-09-2006
Stereo 3D
A cool feature that would be nice to see in GCARS-CS (and which hopefully wouldn't be too hard to program for someone as skilled as Fuzz) would be page-flipped stereoscopic 3D for commercial games. Basically, the way this works is to, each frame, alternately move the camera slightly left and right. When combined with a 3D display, e.g. shutter glasses or an HMD, this results in each eye seeing a different view, with the left eye's camera being slightly more left than the right eye's camera -- in other words, stereoscopic 3D. I have an I-Glasses SVGA 3D display, and I would love to be able to play my GameCube games on it in stereo 3D. For more info on the Nvidia implementation of stereo 3D, their site is at http://www.nvidia.com/object/3d_stereo.html Is this possible?

fuzziqersoftware- 03-09-2006

O.o I'll look into it; this seems interesting.....

Bomb Bloke- 03-15-2006

The only game I've ever seen take advantage of a 3D effect even close to that is Magic Carpet. Stereogram as well as 3D glasses modes! Kinda hard to play via stereograms though, as ALL you get is a sense of depth. Not really relevant here, though it is odd that what with all the computer power available these days, virtual reality hasn't been further pursued.

biolizard89- 03-15-2006

Yeah, I'm kind of surprised stereo 3D hasn't caught on much yet. The Nvidia drivers for it will work with any Nvidia card and any game that uses Direct3D or OpenGL. I actually attemped to use it on my parents' computer, which has a Nvidia card, with an N64 emulator running Star Fox 64, but for some reason the drivers refused to enter 3D mode. They've probably fixed the bug by now (this was like two years ago), but now I'm on a laptop that doesn't have a Nvidia card, and my parents rarely let me on their computer, so I have had no chance to try it out. One thing I thought of that might be a problem in implementing it in GCARS-CS is that some games don't run at 60fps, even though the refresh rate of the Cube's output is 60Hz. The 3D shutter glasses and HMD's will usually switch eye views for each refresh, so it might not work on games not running at 60fps. I have an idea for fixing that, though. Hook the game's routine that actually displays a frame after it's been rendered, and instead, have GCARS-CS store the image in RAM. Then, have GCARS-CS store two images in RAM, the left and right views, and display them, switching between them at 60Hz, while at the same time, only changing the camera view in the game after that eye's image has been updated in GCARS-CS. Obviously, this wouldn't be necessary for games running at 60fps. Yeah, I explained that kind of weird; I hope it's understandable. Would that work?

fuzziqersoftware- 03-15-2006

It looks good, but I don't know if the embedded framebuffer is writeable directly - i.e. I probably couldn't modify the image directly. There's also the matter of how much RAM is available to GCARS-CS - not very much (32K). I think the original idea of moving the camera left and right each frame is the easiest. It may be possible to hook the routine that projects each frame; the camera's location must be passed to it somehow. (If we're lucky, it'll be in the Dolphin OS, so it can be found in every game.)

Bomb Bloke- 03-15-2006

As I understand it (and I'm not sure I do), the glasses have to work via your refresh rate (that is, what comes out on the screen), not the framerate (that is, what the Cube sends to be drawn on the screen). This means that it doesn't really matter what the framerate is, so long as the camera is moved in time to the screen refresh rate. This is fine so long as the game renders at a constant 60fps or higher, but anything less and you won't be able to produce the frames in time. I'm not sure storing the images would work as this just slows the frame rate further, along with the entire game. I don't think the Cube is going to be able to flip between those images at 60hz either, because to do that, it has to process them at 60fps anyway (which, in most cases, it didn't have the power to do in the first place). The frame buffer just regulates the flow of frames to the screen, sending the same frame twice if another one hasn't arrived yet (I think?). On the other hand, just depending on the framerate won't work either, as this is variable depending on what's happening on the screen. I'm pretty sure the I-Glasses would depend on a constant refresh rate. Perhaps you could move the camera angle, tint each image blue or red, and superimpose each new image on a copy of the last? That's one method where the refresh rate doesn't matter so much, even if it is a bit primative.

biolizard89- 03-15-2006

As I understand it (and I'm not sure I do), the glasses have to work via your refresh rate (that is, what comes out on the screen), not the framerate (that is, what the Cube sends to be drawn on the screen). This means that it doesn't really matter what the framerate is, so long as the camera is moved in time to the screen refresh rate. This is fine so long as the game renders at a constant 60fps or higher, but anything less and you won't be able to produce the frames in time. I'm not sure storing the images would work as this just slows the frame rate further, along with the entire game. I don't think the Cube is going to be able to flip between those images at 60hz either, because to do that, it has to process them at 60fps anyway (which, in most cases, it didn't have the power to do in the first place). The frame buffer just regulates the flow of frames to the screen, sending the same frame twice if another one hasn't arrived yet (I think?). On the other hand, just depending on the framerate won't work either, as this is variable depending on what's happening on the screen. I'm pretty sure the I-Glasses would depend on a constant refresh rate. Perhaps you could move the camera angle, tint each image blue or red, and superimpose each new image on a copy of the last? That's one method where the refresh rate doesn't matter so much, even if it is a bit primative. I doubt that flipping between two images at 60fps would take a lot of CPU time, and even if it did, the end result would just be that the framerate for the game would drop slightly; the 60Hz flipping would work fine. FMV playing at 60fps works just fine on the GameCube. That said, there are a lot of games, like F-Zero GX, that render at 60fps no matter what. So those games wouldn't even need any type of image storing.

Forumer™ is Voted #1 Free Forum Hosting provider
Build your own community today with the largest message board hosting company.