Comment Re:Limitations (Score 1) 157
The issues here are framerate and buffering.
Computer displays are double buffered. That is, you have an image being displayed and an image being drawn to. Finish drawing and you flip them. This is all well and good, but a 1080p 32 bit display takes 8 Megs. We need another 8 for the back buffer, possibly another 8 for a depth buffer and the same again for player 2. That's 48 Megs allocated just to drawing the graphics. You might be able to do something simpler with triple buffering but that doesn't save you a lot.
Framerate - we're drawing twice as many pixels and twice as many polygons. There's very little scope for optimisation here.
If you can make the scene a lot simpler, then you can actually gain in both of these. If you are absolutely certain that a display will be drawn in less than a sixtieth of a second, then you can just draw that while the other image is visible. This means you only need a single buffer per player. You might even find another way of dealing with depth if things are simple enough.
Computer displays are double buffered. That is, you have an image being displayed and an image being drawn to. Finish drawing and you flip them. This is all well and good, but a 1080p 32 bit display takes 8 Megs. We need another 8 for the back buffer, possibly another 8 for a depth buffer and the same again for player 2. That's 48 Megs allocated just to drawing the graphics. You might be able to do something simpler with triple buffering but that doesn't save you a lot.
Framerate - we're drawing twice as many pixels and twice as many polygons. There's very little scope for optimisation here.
If you can make the scene a lot simpler, then you can actually gain in both of these. If you are absolutely certain that a display will be drawn in less than a sixtieth of a second, then you can just draw that while the other image is visible. This means you only need a single buffer per player. You might even find another way of dealing with depth if things are simple enough.
