It’s finally happening for real this time! Working behind the scenes with some community members, I decided to take an honest swing at an in-house PVB emulator at a full-time capacity. This will be my actual day job. So for the first time in history, I’m going to put my skills to work and produce some actual results. (-:
This community has always been amazing, and I have a good feeling about the emulator initiative going forward. The official project page can be found here:
http://perfectkiosk.net/
__________
So why should you care? Aren’t there Virtual Boy emulators out there already? Let’s see what the project page has to say…
The initiative has four primary objectives:
Nintendo 3DS Emulator
I’m sure most of us thought about Virtual Boy when we first heard about the Nintendo 3DS. A custom emulator specifically designed to run on 3DS can take full advantage of the system’s power and capabilities, giving us true stereo Virtual Boy on the go.
Reverse Engineering
Any time we want to learn about how a game works or make changes to it, we need the right tools to dig in and take a look around. A cross-platform desktop application is just the ticket for providing the user with the right kit to expose all the deepest secrets buried within Virtual Boy software.
TAS
The tool-assisted speedrun is a cornerstone of video game culture, and like reverse engineering, we need the right tools at our disposal in order to get the job done right. The aforementioned desktop application pulls double duty by bringing TAS-focused utilities to the party.
Documentation
Comprehensive documentation of the Virtual Boy’s internals will come from emulator research, and it’s a perfect way for homebrew authors and modders to learn about the system’s features. Those who remember the Sacred Tech Scroll document I wrote can look forward to a brand new version of it.
For further reading of what exactly is planned, refer to the technical document trail on the project page.
__________
How exactly are we gonna pull this off? Glad you asked…
I have enough money in savings to begin work immediately (2018-04-18), but within a few weeks, I’m going to need to rely on financial support from the gaming community. We’ll be reaching out to other sites to gather support, since this undertaking spans a broader scope than what solely applies to Planet Virtual Boy.
A conservative estimate of my monthly expenses comes out to around $500 USD, and with enough interest, I’ll be able to keep this up full-time. By “full-time”, what I mean is 40 productive hours every single week, with status reports and a detailed outline of the development requirements. Planet Virtual Boy has its own developer working for it to make this dream come true. (-:
Donations are managed through a Patreon page:
https://patreon.com/GuyPerfect
__________
For now, this thread will be the place to be notified of progress and for general discussion of the initiative. Thanks again for being such a great community, and for giving me a chance to do what I really love. <3
Special thanks to Fire-WSP, STEREO BOY and KR155E for their assistance in getting the ball rolling.
--Guy Perfect
This is a work post.
Still working on the VIP debugger window, but I’ve finally hammered out all the rough spots and what’s left is just a matter of sitting down and doing it–which is quite fun and has been keeping me awake at night! I’d be farther along by now, of course, but a day went to R&D regarding the character subsystem and another day went to replacing my hot water heater… But that hasn’t discouraged progress, no siree.
Attached to this post is a JAR file containing the current build of the application, which contains the Characters and BG Maps tabs of the VIP debugger window. I reworked several things on the back-end to improve simplicity and resource management, and the GridBagLayout error I was encountering before seems to have vanished, so that’s good.
Let’s take a quick look at what’s in there…
Characters
All of the features for this tab are the same as they were in this post, but the presentation is a bit different. You can view all 2,048 character patterns in VIP memory, previewing with any palette or a set of generic colors, and even edit the pixel data by hand.
BG Maps
New to the party is this tab, which displays any of the 64×64 character BG maps in VIP memory. Each individual cell of a BG map contains various properties, such as which character to draw, with what palette, and any flipping that needs to be applied. As expected, all fields can be edited to apply changes back into the emulation state.
The upper Index field selects the BG map displayed in the window, from 0 to 15.
The Index field inside the Cell group selects the global BG map cell, which starts at 0 for the first cell in BG map 0 all the way up to 65535, which technically comes from memory reserved for OBJ attributes, but can be indexed as though it were the 4,096th cell of BG map 15. Changing this field will update the contents of the window to display the corresponding cell from the correct BG map.
Alternatively, the Address field allows you to enter the exact bus address of the cell to select, which will likewise update the window accordingly.
Character, Palette, Horizontal flip and Vertical flip are the formal properties of the selected cell. Only BG palettes can be used here for obvious reasons. Changing any of these fields will write changes back into the emulation state and update the contents of the debugger UI.
Scale works as it does on the Characters tab: by sliding it to the right, the preview of the BG map in the right-hand region of the window will grow.
Checking “Generic colors” will use the generic red gradient colors for all characters in the display. This is primarily useful for previewing graphics while the brightness settings of the VIP are dark or invisible, but ordinarily you won’t need to use it.
Checking “Show grid” will display a grid pattern between BG map cells as seen on the Characters tab. This can be useful for identifying the scope of a cell when the pixels it represents blend together with neighboring cells.
Attachments:
This is a work post.
Okay, I admit, I slouched a bit for a couple of days. I was thinking the project would get demoted to “personal project” status and didn’t really grind at it like I have been. But since it’s once again officially my job, I went ahead and finished up the Objects tab this afternoon:
By this point you know what to expect from those controls on the left. Editing those will change the current emulation state to match.
The right-hand side is a different story. That area displays a simulation of what the object looks like in the scene. The black rectangle is 384×224 pixels, which is the size of the system’s frame buffer. So by previewing an object in this tab, you’ll see exactly where and how it contributes to the final frame image.
This marks the first instance of stereoscopy in the project. The only available method to achieve this in Java is the usual anaglyph, which encodes each eye’s image with specific colors such that they can be masked out for the appropriate eye with a set of 3D glasses worn by the viewer.
The most common anaglyph configuration is red for the left eye and cyan for the right eye. Ordinarily this can lead to a color imbalance because of the way the human eye is more sensitive to green light than either red or blue light, causing erroneous distribution of light intensity for each eye.
However, as you can see in this macro example, the overlapping pixels are not white, but sort of a light peach color. I’ve done my best to equalize the apparent intensity of colors by default, although this will of course be configurable by the user.
Because the human eye is so sensitive to green light as compared to red and blue, I recommend using green-magenta anaglyph glasses instead of red-cyan, if you can get your hands on some. I want to say it’s fairly common in the wild, so it shouldn’t be hard to find a set. The amount of color correction needed for this combination is less than in the first example.
