I have been thinking about design tricks and came up with a question to those who have worked with direct screen draw: is it possible (and feasible) to do “post processing” on the Virtual Boy? i.e. can we manipulate the frame buffers after the VIP has done its job and written the next frame to it?

I am thinking about a full screen HBias effect as en example, where we shift some rows by some pixels to create a wavy screen. Another example would be to only render to a fourth of the screen through the VIP and then scale that portion up to full screen by replacing each pixel of the original image with four pixels. Yet another example would be to add “glitches” of various kinds, like offsetting some rows, inverting portions of the screen, etc.

KR155E wrote:
I have been thinking about design tricks and came up with a question to those who have worked with direct screen draw: is it possible (and feasible) to do “post processing” on the Virtual Boy? i.e. can we manipulate the frame buffers after the VIP has done its job and written the next frame to it?

Yep. In fact you pretty much have to wait until the VIP is done drawing to ensure that what you write will not be overwritten by the VIP’s blitting ops. Granted, if the VIP is pretty busy during a frame, you won’t have much time to do your own direct drawing, but if you had to you probably could play with the FRMCYC register to allow yourself more time, at the expense of framerate. I suppose if you were *really* careful with your timing you could “race the beam” and do your direct drawing in parallel with the VIP, but the exact timings of where and when the VIP blits pixels during its busy stage is a mystery to me.

I am thinking about a full screen HBias effect as en example, where we shift some rows by some pixels to create a wavy screen. Another example would be to only render to a fourth of the screen through the VIP and then scale that portion up to full screen by replacing each pixel of the original image with four pixels.

These things are all technically possible, however they are very slow, as they all have to be done in software. You probably could pull it off at full framerate with clever coding, a sparse scene for the VIP to render, and not much else going on in your game loop, but as an example, my dither demo runs at almost fullscreen and doesn’t run at 50Hz. I’d have to rewrite it in asm to squeeze more speed out of it, and that’s with nothing else happening in my loop.

Yet another example would be to add “glitches” of various kinds, like offsetting some rows, inverting portions of the screen, etc.

Small effects that are localized to portions of the screen are better candidates as general case effects IMO.

KR155E wrote:
I have been thinking about design tricks and came up with a question to those who have worked with direct screen draw: is it possible (and feasible) to do “post processing” on the Virtual Boy? i.e. can we manipulate the frame buffers after the VIP has done its job and written the next frame to it?

Yes, framebuffer memory can be accessed by the CPU after VIP drawing operations but before scanning to the displays. It’s certainly possible. Feasible, like blitter shows, is another matter. (-:

The VIP bus is slower than the CPU bus, so you need to make every access count. Reading from VIP memory then writing back to the same address is two accesses, whereas direct rendering generally only requires writes. The big bottleneck here is going to be transfer speed.

KR155E wrote:
I am thinking about a full screen HBias effect as en example, where we shift some rows by some pixels to create a wavy screen.

Know that framebuffer memory is stored with column-major ordering (top-to-bottom, then left-to-right), so to shift rows of pixels horizontally is going to be a beast to process. I’d have to try it, but I’m not sure there’s enough time even after a blank VIP drawing operation with zero windows to pull this off.

KR155E wrote:
Another example would be […] Yet another example […]

Since the time available after VIP processing but before display scanning is so small, I really think it would be more worthwhile to do CPU rendering before the VIP drawing procedure, uploading it to CHR memory instead of framebuffer memory. While there’s not enough CHR memory for two fullscreen blits in this manner, you could still go a long way if you’re clever with it. There’s way more than enough time to write all 2048 CHR blocks per frame than reading and writing both framebuffers after VIP drawing but before display. Plus, you’d get to use the entire drawing and display time preparing the graphics for the next frame.

Guy Perfect wrote:

KR155E wrote:
I have been thinking about design tricks and came up with a question to those who have worked with direct screen draw: is it possible (and feasible) to do “post processing” on the Virtual Boy? i.e. can we manipulate the frame buffers after the VIP has done its job and written the next frame to it?

Yes, framebuffer memory can be accessed by the CPU after VIP drawing operations but before scanning to the displays. It’s certainly possible. Feasible, like blitter shows, is another matter. (-:

Any plans to RE the VIP timings so that I *can* race the beam? While its utility might be limited, it’d be pretty cool regardless. 😀

blitter wrote:
Any plans to RE the VIP timings so that I *can* race the beam?

I’d like to eventually. It’s an after-project of the emulator thing, but not immediately something I expect to spend a lot of time on. The initial implementation of the VIP emulator will probably just render the whole darn thing on the first CPU cycle each frame until we can get the various timing mechanics figured out.

On the other hand, if we’re going to set up a PVB task force to work on this, I’ll gladly pitch in.

Guy Perfect wrote:

blitter wrote:
Any plans to RE the VIP timings so that I *can* race the beam?

I’d like to eventually. It’s an after-project of the emulator thing, but not immediately something I expect to spend a lot of time on. The initial implementation of the VIP emulator will probably just render the whole darn thing on the first CPU cycle each frame until we can get the various timing mechanics figured out.

On the other hand, if we’re going to set up a PVB task force to work on this, I’ll gladly pitch in.

Agreed. I would if I could.

Thanks for the expertise guys! I already suspected it to be possible, but very limited due to performance reasons. I still hope that this technique can be used for some simple effects.

I also talked to jorgeche about that topic in Skype and he liked the idea very much. The next day, he had added generic support for it to the VBJaEngine that lets you register any number of post-processing effects. Complete with a dynamic lighting sample effect that lightens up a box around the hero in our Platformer Demo. And the best part: there seems to be next to no performance penalty involved at all since the effect only affects a small portion of the screen. (In the emulator at least, have not yet tested on hardware.) 🙂

Here’s a proof of concept, a full-screen vertical wave effect applied to the VBJaEngine Platformer Demo! Amazingly, the performance is hardly affected by it, at least on Mednafen. I assume that it’s not that great on hardware, but I am too afraid to test. 😉

Attachments:

1. 

   output-0000.png
   

1. output.vb

KR155E wrote:
Here’s a proof of concept, a full-screen vertical wave effect applied to the VBJaEngine Platformer Demo! Amazingly, the performance is hardly affected by it, at least on Mednafen. I assume that it’s not that great on hardware, but I am too afraid to test. 😉

In my experience Mednafen always runs faster than real hardware, but I can’t always tell how much until I actually measure it.