You are not logged in.
Lost Password?


Register To Post



 Bottom   Previous Topic   Next Topic

#41
Re: PVB Emulator & Fundraiser
Posted on: 5/16 20:43
VUE(xpert)
Joined 2012/12/4
383 Posts
CoderLong Time User (5 Years)
This is a work post.

Here comes Tenerence Love with an R&D break! Progress on the VIP debugger window is going great, but before I go any further on it, I need to get all my ducks in a row or else face the reality of a bogged-down, ham-fisted kludge of an implementation. And no one wants that.


Progress So Far

The interface for the Characters tab is all done and lookin' snazzy:

Open in new window


On the right is a list of all 2,048 character patterns currently in CHR RAM. They can be displayed at a configurable scale and palette.

One character is always the focus of attention, which is displayed with jumbo proportions in the top-left corner. It has an index and an address, as well as an address mirror that you can read about here. All three of those controls can be edited by the user in order to select the character they're most interested in. You can also just click on it in the list on the right if you can find it.

The Scale slider affects the size of the list of characters over on the right-hand side. In the image, they're being displayed with a scale of 3×.

One of nine palettes can be selected, which is applied to every character in the window. The four BG palettes, four OBJ palettes and a generic palette can be used. The generic palette is a conventional red gradient that is useful for identifying the exact pixel values as well as previewing patterns while the brightness settings are all black (which is the case in Wario Land's startup screen). The exact colors being displayed for each pixel value are shown as large squares below the palette combo box.

You'll notice one of the shades of red is selected and that there is a smiley face inside the "O" of "IMPORTANT". That's because this interface allows the user to modify the contents of character memory visually at runtime.

Keen observers will note that the black pixels in the output are not fully black: they are a wee bit translucent to let the background window color show through a little bit. This is because black is a valid color for palette entries, so it's necessary to be able to distinguish between black pixels and empty pixels. I tried drawing no color at all for empty pixels, but red on light gray looks very very bad.


The Hold-Up

So if things are going so swimmingly, what's the problem? Well, there's no problem. Yet. And I would like that there never is one, so I need to do some research to determine a satisfactory solution to the upcoming design challenge...

Java has a feature-rich 2D graphics infrastructure that offers hardware acceleration for things such as drawing and filling paths with textures and gradients, or painting image contents, all of which can be transformed and displayed at arbitrary scales and orientations. However, all that fanciness is not well-suited for the type of graphics work being done here, where volatile pixel patterns are used to construct larger images.

Ideally, when drawing images in Java, the contents of the images need to be static so that the JVM can cache them efficiently in order to make the most effective use of the hardware. If the images keeps changing, which is the case for characters in Virtual Boy video memory, that cached data is quickly invalidated and more time winds up getting spent on the caching process than the drawing process by the time it's all said and done. That's the problem: the usual Java approach won't work here.

Granted, the official JVM is also very smart and should be able to optimize image memory performance based on how it's being used. I don't know for sure if that's the case, but even if it is, there are still challenges going forward with regards to composing larger images with character data. Background maps and worlds (namely affine worlds) need to be able to sample from character memory arbitrarily, putting me in a situation where all of the rendering gets done in software in the end regardless. And while that is an option, I'd like to come up with a way to solve both problems with one... stone.

What I would like to do is fairly simple in OpenGL:

• Supply the rendering system with one image containing all character patterns in a 2bpp format
• Sample from any location of any character with or without flipping
• Apply a 4-color palette to the character samples
• Apply transformations to source coordinates in order to sample from normal, H-bias or affine backgrounds

From what I've seen so far, this should be doable in Java, although it requires me implementing my own Raster objects among other things. I don't know how long I'll spend working on this (shouldn't be more than a couple days), but I can't progress with the VIP debugger until I sort it all out.

Stay tuned! This thing keeps on getting better.

Attach file:



png  SoFar.png (12.42 KB)
3060_5afc748217b9c.png 640X480 px
Top

#42
Re: PVB Emulator & Fundraiser
Posted on: 5/17 4:32
VUE(xpert)
Joined 2012/12/4
383 Posts
CoderLong Time User (5 Years)
To the future Java developer who stumbles on this thread in a web search while trying to do something similar:

Modern Java applications use the Swing API for user interface stuff. The JComponent class used by all Swing controls supplies a pantComponent() method, which can be overridden to provide arbitrary graphical commands to the Java2D graphical subsystem each time the component is drawn to the screen. While paintComponent() receives a Graphics object as its argument, it is an instance of Graphics2D and can safely be cast as such.

If you intend to circumvent the intrinsic drawing functionality provided by Java2D, the most comprehensive low-level control over pixel operations is given by Graphics2D.setComposite() using a custom Composite object. In doing so, you'll ultimately implement CompositeContext.compose(), which operates on two input Raster objects (one for input source pixels and one for input destination pixels), and a WriteableRaster object for output.

When performing raster operations, you get access to individual component samples for each pixel in the area to be drawn for both the input and output contexts. Care must be taken, as the storage primitive type and number of components per pixel may be different between source and destination. While the methods to access pixel data are able to do type conversions for you, the logic regarding how many components each pixel has is the responsibility of the program. Furthermore, I couldn't find any simple way to determine the significance of the ordering of pixel components (Does red come first? Last? How about alpha?), but I didn't really look into it...

Note: Composite requires the execution environment to be allowed to read pixels from the device. This is a potential security risk and may be restricted in some cases such as applets.

While it's absolutely possible to, for instance, process all of the transformations necessary to render an affine world from within a Composite object, performance considerations suggest that might not be a great idea. Java2D is capable of optimizing image processing through a number of means, most notably caching the contents of BufferedImage objects in some device-compatible way. Accessing simulated VIP memory each time an image is drawn makes caching completely impossible and offers no benefits over pre-rendering the world into a BufferedImage to begin with.

On the opposite end of the spectrum, the VIP debugger window allows the user to select which palette to preview graphics with, meaning just one cached BufferedImage isn't sufficient for every variation on the output for any given image.

At first I considered using indexed colors on a BufferedImage object. The idea was that the pixel data can be cached as usual, but before drawing the image I could update the palette according to the colors I needed it to use. However, BufferedImage color models happen to be immutable, preventing this from being an option.

The only other solution I found was the variant of Graphics2D.drawImage() that accepts a BufferedImageOp. The filter() method of BufferedImageOp accepts a BufferedImage as input and transforms its pixels (coordinates and colors) into an output BufferedImage. Bulk operations can be performed via getRGB() and setRGB() as usual, and a palette can be dynamically applied to an image in this manner.

While at face value it doesn't look like this approach would provide any benefits over changing the contents of the source BufferedImage before drawing it, it's quite likely that the destination BufferedImage object passed to the filter() method is of a different disposition than the ones you can create in userland. According to accounts from developers who have used BufferedImageOp, its performance benefits are significant.

Tomorrow, I will rework the Characters tab to use this technique and then I'll be able to move onto the remaining tabs.
Top

#43
Re: PVB Emulator & Fundraiser
Posted on: 5/17 9:46
VB Gamer
Joined 2012/4/28
25 Posts
Long Time User (6 Years)
Great work Guy!

I'm trying to work out how you're going to have to pull this off. The character memory looks good; I like all the options. So now you have to do the Background Segments, Object memory, and Windows. That's going to be intense!

Since those sections of memory all reference char memory, are you going to be able to visually show each of those memory spaces? Maybe if you're looking at a background segment, when you hover over a tile, you can see the values of all the fields in that cell.

And then with all the VIP registers, it would be cool to have those all transformed in to a readable table. It's just too cool man!
Top

#44
Re: PVB Emulator & Fundraiser
Posted on: 5/17 18:43
VUE(xpert)
Joined 2012/12/4
383 Posts
CoderLong Time User (5 Years)
Well, I'm not happy with BufferedImageOp's performance. I'm afraid we might have to let him go...

Before resorting to the Composite approach, I took the YOLO route and just told the characters to draw themselves to the screen using the built-in Graphics.fillRect() method, one for each pixel of each character being drawn... And it really worked quite well! Ordinarily I hate the idea of calling a graphics method on a per-pixel basis, but when that's the fastest solution available, sometimes crazy ideas pan out!



Quote:

Yeti_dude wrote:
Since those sections of memory all reference char memory, are you going to be able to visually show each of those memory spaces? Maybe if you're looking at a background segment, when you hover over a tile, you can see the values of all the fields in that cell.

You've got the right idea. Each graphical element type will have its own tab: these include Characters, BG Maps, Objects, Worlds and Frame Buffer. All of the properties of all of them will be user-editable right there in the VIP debugger window.

I'm not a believer of the mouse-hover ideology, so in this software, if you want to select a character for review from the output, you have to click on it. The idea is that actions are dictated by the user, and it's up to them to decide what happens. It's kinda like a link in a web page opening a new browser tab or window. That's discouraged, since a middle-click or control-click will explicitly do that anyway, so links should never try to make that decision for the user.
Top

#45
Re: PVB Emulator & Fundraiser
Posted on: 5/19 5:05
VUE(xpert)
Joined 2012/12/4
383 Posts
CoderLong Time User (5 Years)
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

Open in new window

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

Open in new window

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.

Attach file:


jar vbemu_20180518.jar Size: 149.21 KB; Hits: 20

png  Characters.png (14.04 KB)
3060_5aff90e9f2f29.png 640X480 px

png  BGMaps.png (16.21 KB)
3060_5aff90ede2c53.png 640X480 px
Top

#46
Re: PVB Emulator & Fundraiser
Posted on: 5/20 6:44
VB Gamer
Joined 2017/6/24
USA
32 Posts
Long Time User (1 Year)
Looks like Wario Land's precaution screen has an easter egg. The O in "IMPORTANT:" has a smiley face in it.
Top

#47
Re: PVB Emulator & Fundraiser
Posted on: 5/22 4:50
VUE(xpert)
Joined 2012/12/4
383 Posts
CoderLong Time User (5 Years)
This is a work post.

Development of VIP debugger tabs is ongoing, creeping steadily closer to its completed state. I keep reworking the back-end, since every iteration brings new insights and I want to make sure it's as good as it can be while still fulfilling all of the requirements. I feel like I've boiled it down to its essential format now, so fortunately all that's left is plopping down some controls and coding in their event handlers.

Working with the Java2D API has been a reliable headache since I started work on this window. It's completely lacking what I consider to be basic, barebones functionality such as volatile palettes and rudimentary block transfer compositing, and working around that has been an exercise in head-shakery. What I ultimately wound up with has the best performance of everything I tried, but I'll always know that behind the scenes, it's inelegant and sub-optimal. Perhaps it's not one of the intended uses of Java2D, but they wouldn't have to go out of their way to support doing stuff like this...

On the bright side, this window is the last big chunk of the picky graphics stuff. What's left after this is sweet, sweet data-centric processing that I do have control over. The worst is nearly over. (-:


Important Notice

Once again, I'd like to thank all of the financial supporters, Patreon or otherwise.

The good news is that in a little over a month, 18 Patrons have pledged $122/mo (gross), and that's awesome! It's good to know that Virtual Boy still means enough to people that they'd be willing to support something like this, especially considering the only real confidence they had was that some dude said he was worth it.

The bad news is that in a little over a month, the level of interest has pretty much established itself and settled in place. Regrettably, the bills don't have the same enthusiasm for Virtual Boy that the rest of us do. There's no great way to say it, but the truth is that the current level of support is insufficient to keep the project moving at its current pace. I unfortunately don't think it will be sustainable going forward.

Later this week, in the interest of living indoors and eating food daily, I will be submitting applications for employment seeking another source of income. Depending on how that goes, my time to work on the emulator initiative may become limited, being relegated to time off that isn't spent doing other things. I will continue to work at it on at least a weekly basis at worst, but it won't be anything like this past month.

To the current Patrons: be advised that beginning in the month of June, I will likely be doing other work instead of focusing on this emulator initiative. I don't want anyone to feel betrayed by sending their money into a black hole--if you chose to donate in the interest of producing results, then you may consider canceling your Patronage, as I can't guarantee that your generosity will be spent towards that end.

To everyone, know that the project isn't dying--far from it. This is still my passion and is first-and-foremost in my list of things to do in my spare time. I may not end up getting to do this as my day job, but at least for the last month I did get to live that dream. (-:
Top

#48
Re: PVB Emulator & Fundraiser
Posted on: 5/22 13:52
VB Gamer
Joined 2015/7/18
Australia
17 Posts
Long Time User (3 Years)
I was wondering when this would happen, but I still have faith in this project (even if I regrettably cannot invest) - you're doing a great job GuyPerfect, so keep on chipping away at it!
Top

#49
Re: PVB Emulator & Fundraiser
Posted on: 5/22 16:08
VUE(xpert)
Joined 2014/6/4
USA
496 Posts
Long Time User (4 Years) 20+ Game Ratings
I'm sorry I wasn't able to really contribute. I wish I had a job so I could throw you guys money for these projects. Good luck with job hunting. It's the biggest hurdle.
Top

#50
Re: PVB Emulator & Fundraiser
Posted on: 5/24 20:19
VUE(xpert)
Joined 2012/12/4
383 Posts
CoderLong Time User (5 Years)
In light of the recent situation, an anonymous benefactor plunked down enough money to keep the project going for a couple more months. We back in business, bois!
Top

 Top   Previous Topic   Next Topic


Register To Post