I’m curious about something concerning the VB system, is the overall processing power divided between the two screens? Is the VB twice as powerful if it only has to draw to one of the screens?

No… not really. Most games simply use the parallax value to give sprites a different offset on the left and right screen, which is no more work than making that the same on both screens (parallax of 0), or even simply turning off one screen.

Even if it does individually draw the left and right eyes, most games don’t have their CPU completely consumed by drawing graphics (ideally, the game logic would be somewhat complex and not just a graphics demo). Even something like a raycaster engine should only use marginally more processing by drawing two eyes, since it’s still tracing the same rays… just manually computing the parallax and writing to two different frame buffer locations.

Where it would consume nearly double the computing power is a graphics demo with a complex graphics engine, accurately computed for the view of each eye (similar to how current VR systems compute the scene from each eye). It doesn’t make much sense to do for the VB, but it could be done.

DogP

So in a sense, the VB works because it can generate one screen and slightly adjust for parallax when copying to the framebuffers for both displays.

Would the VB’s power be cut in half if it had to draw two completely different screens at the same time?

No not really. A small part of the CPU’s time is dedicated to setting up the VIP to draw. If it had to draw two completely different screens then the worst that would happen is that the rendering code would take twice as long, but that wouldn’t be half the time in a typical game. The remainder of the frame time is used by the CPU to do things like game logic, sound, etc. that are independent of how much is rendered.

3DBoyColor wrote:
Would the VB’s power be cut in half if it had to draw two completely different screens at the same time?

If you want to basically cut the VB’s processing power in half, have it play two completely different games… one using the left screen, speaker, buttons, etc… and the other using the right ones. 😉

DogP

DogP wrote:

3DBoyColor wrote:
Would the VB’s power be cut in half if it had to draw two completely different screens at the same time?

If you want to basically cut the VB’s processing power in half, have it play two completely different games… one using the left screen, speaker, buttons, etc… and the other using the right ones. 😉

DogP

Heh, that could actually be interesting. Like playing Tetris on one eye while playing Breakout on the other. I bet Ben can do it.

3DBoyColor wrote:
I’m curious about something concerning the VB system, is the overall processing power divided between the two screens?

Graphics are usually handled by a dedicated video component in the hardware called VIP (Virtual Image Processor). The CPU overhead for configuring the VIP is usually negligible. You could run into trouble trying to do realtime affine calculations, but most people don’t. (-:

3DBoyColor wrote:
Is the VB twice as powerful if it only has to draw to one of the screens?

As before, the CPU won’t be weighed down one way or the other, so that’s not an issue. Though disabling video could conceivably utilize the VIP as a makeshift coprocessor if you were clever about it… I think you just nerd sniped me.

Having said that, the VIP does draw frames discretely with a top-down procedure, though reverse engineering exactly what that procedure involves is a month-long project in an of itself. What I can say about it is that in profiling experiments, I did not see an increase in drawing capacity when disabling drawing to one display. Apparently it does all the pixel calculations, but at the last moment decides whether or not to apply them.

DogP wrote:

3DBoyColor wrote:
Would the VB’s power be cut in half if it had to draw two completely different screens at the same time?

If you want to basically cut the VB’s processing power in half, have it play two completely different games… one using the left screen, speaker, buttons, etc… and the other using the right ones. 😉

DogP

Ah ok I see, so the VIP and CPU together account for the overall system.

While on the subject, is the VB better at drawing 2D graphics than polygons? Does the VIP have any polygon rendering capability, or is it all software rendered using the CPU?

Guy Perfect wrote:
Graphics are usually handled by a dedicated video component in the hardware called VIP (Virtual Image Processor). The CPU overhead for configuring the VIP is usually negligible. You could run into trouble trying to do realtime affine calculations, but most people don’t. (-:

The VB is sounding like a very efficiently designed system, especially with dual high resolution screens. Nintendo doesn’t get enough credit.

Guy Perfect wrote:
As before, the CPU won’t be weighed down one way or the other, so that’s not an issue. Though disabling video could conceivably utilize the VIP as a makeshift coprocessor if you were clever about it… I think you just nerd sniped me.

Having said that, the VIP does draw frames discretely with a top-down procedure, though reverse engineering exactly what that procedure involves is a month-long project in an of itself. What I can say about it is that in profiling experiments, I did not see an increase in drawing capacity when disabling drawing to one display. Apparently it does all the pixel calculations, but at the last moment decides whether or not to apply them.

Bwahaha… I seem to have that effect on people sometimes.

Would you say the VB was designed to be easy to program? Or at least that’s what the hardware layout sounds like to me. Most other game consoles have a more complicated dynamic between the CPU, GFX chipset and the rest of the system. The VIP sounds like it takes care of some of the more menial tasks involved with drawing the screens. Are programmers allowed much flexibility? Can it do raster effects? Or other unusual visual effects?

In Mario’s Tennis, a landscape effect is in use, like what is seen on the SNES (and other consoles if done in software). Is that landscape effect a hardware feature? Or is it done in software too? I’ve often wondered how much more powerful the VB is over the SNES.

One other question, I know this would largely be a waste of time, but would the VB benefit from a co-processor on the cartridge? Think like the SNES. Or is it plenty powerful enough on its own (sort of like a GBA).

3DBoyColor wrote:
Does the VIP have any polygon rendering capability, or is it all software rendered using the CPU?

The VIP is only designed to do 2D. It does have an affine feature (most often compared with the SNES “mode 7”) which can be used to simulate perspective, but it still amounts to processing in 2D the way it works. All “true 3D” or polygon-based graphics on Virtual Boy need to be done in software by the CPU, then transferred as completed 2D images to the VIP for display.

A common way to do this is to turn off the VIP’s drawing feature entirely and just have the CPU write to framebuffer memory directly.

3DBoyColor wrote:
Would you say the VB was designed to be easy to program? Or at least that’s what the hardware layout sounds like to me. Most other game consoles have a more complicated dynamic between the CPU, GFX chipset and the rest of the system.

Absolutely. For what each of the hardware components do, the way to do it from the CPU’s perspective is fairly simple and intuitive. The only real beef I have with any piece of Virtual Boy hardware is the fact that PCM wave buffers on the audio unit can’t be written to while audio is being generated, effectively locking you into five distinct waveforms unless you interrupt the sound…

3DBoyColor wrote:
The VIP sounds like it takes care of some of the more menial tasks involved with drawing the screens. Are programmers allowed much flexibility? Can it do raster effects? Or other unusual visual effects?

The VIP has the usual graphical setup: memory for 8×8-pixel character patterns (or “tiles”) and memory for “backgrounds”, which are gridlike canvases where you can arrange characters/tiles. It takes it a step further and lets you define individual windows, which have on-screen positions and dimensions, inside of which background segments can be arranged and scrolled around.

In addition to the usual “scrolling background” setup, windows can also shift individual lines of pixels horizontally by some amount, or the earlier-mentioned affine mode, which samples from backgrounds in a row of pixels in some direction other than “one pixel at a time left to right”

There are also “objects”, or “sprites”, which are individual 8×8-pixel characters that can float around the screen at arbitrary positions. These are traditionally used for anything in the scene that needs to move with pixel precision, but VB’s windowed setup allows you to do the same thing with backgrounds as well.

3DBoyColor wrote:
In Mario’s Tennis, a landscape effect is in use, like what is seen on the SNES (and other consoles if done in software). Is that landscape effect a hardware feature? Or is it done in software too? I’ve often wondered how much more powerful the VB is over the SNES.

It’s a little of both. This is an application of sampling a window background in affine mode. The gist of it is that, for each row of pixels, there’s a starting position (precise to a fraction of a pixel), and a direction–an amount by which the source position in the background will change for each horizontal pixel in the window. This vector is expressed as the change in X and Y distances.

A simple affine effect might sample with a Y of 0 and an X of -1, which would effectively sample exactly one pixel at a time from input, but right-to-left, causing it to be horizontally flipped. Other values for X and Y can be useful for scaling, rotating or perspective effects.

Specifying these affine parameters is another matter that requires the CPU to supply the needed information. The F-Zero tech I made a while back uses a lookup table to accelerate the process of getting information to the VIP, but the code that produced that table absolutely exists in the source and will run on the hardware–albeit with a lower framerate.

The same approach is used on SNES, except SNES doesn’t allow the application to specify affine parameters for each individual row of pixels as far as I know. The program actually has to wait for each row to be drawn, then reconfigure the affine parameters before the next row is processed. The original F-Zero really was a piece of work.

3DBoyColor wrote:
One other question, I know this would largely be a waste of time, but would the VB benefit from a co-processor on the cartridge? Think like the SNES. Or is it plenty powerful enough on its own (sort of like a GBA).

I’ve thought a lot about cartridge wingdings. It could absolutely benefit from in-cartridge processing, especially with the technology we have to work with nowadays. More than anything, though, I’d really love to see some better audio features. I mean, the audio lines do run through the cartridge before they go out to the speakers…