Emulators allow us to not only play, but even enhance games for old (gaming) systems. With that in mind, I had an idea for a possible Reality Boy feature: Color Patches for Virtual Boy games! How would that work? The emulator would load a special (XML?) file associated with a VB Rom you want to play. Before rendering the image output, it looks up RGB colors in that file and replaces the colors before it outputs the game image.

A pretty simple concept. Now, we could enhance that concept by assigning different replacement pallettes for different sprites, backgrounds etc if we find a way to associate pallettes to objects. For example: In Mario Clash, our Color Patch XML file has individual pallettes for Mario, Goomba, Koopa, backgrounds, etc, making a full colored game. Something like:

—Mario
—1
— —-<1>000000
—-<2>c0c0c0
—-<3>123456
—-<4>ffffff
—

What do you guys think, is this technically possible, or am I dreaming too much? 🙂

While I have no idea if it is possible from a technical stand point, I say leave the games as is. Call me crazy, but I think part of the charm of the Virtual Boy is that everything is red.

I wouldn’t mind playing water world in the colour blue, in 3D on the emulator if this is what you are sorta talking about?

mathew schrieb:
I wouldn’t mind playing water world in the colour blue, in 3D on the emulator if this is what you are sorta talking about?

Right! When I find the time, I’ll do a colored mockup screenshot.

That’s a cool idea… like Super Game Boy. It could easily be done to set a certain shade of red to one color (and even different colors depending on the BRT regs), but it’d definitely be tougher to set colors for specific sprites.

DogP

While it would be difficult (but not impossible) to assign certain colors to specific sprites, we aren’t necessarily restricted to just four colors, either. There are four palettes for BGMaps and another four for Objects, so you could in theory have 25 on-screen colors (every palette has three colors; color 0 is always transparent).

I once had idea that takes this to the next level: use some otherwise unused (or read-only) memory locations in the VB’s memory map to allow homebrew games to assign their own colors for each of the palettes (or maybe even for each individual Character).

Here’s an edited screendump of Mario’s Tennis from this site. Made with Paint.

Attachments:

1. 

   marios-tennis-color.png
   

Hey that picture looks pretty cool!

Oh my god that picture looks great, I never would have guessed that it would have looked that way in color, awesome job man.

Thanks!

This is totally possible for the sprite based games. Runtime graphics games like red alert are another story.

I just had the same idea today actually, I even went so far as to download the emulator reality boy’s source. I was going to post this idea just now but thankfully I did a search first.

Ok so I’m new to the VB dev scene so grant me a little bit of theory here, but I’m really familiar with DS and GBA development. (see proof: http://dsquake.blogspot.com/ ) I’m sure most of you know this but these “character” based rendering systems arrange sprites/graphics in small tiles 4×4 or 8×8 depending. I made sure this was the same basic concept with the VB when I looked at the source code.

So backgrounds and objects(sprites) are comprised of just a few things which we would have to map to some outside patched/graphics. the characters(tiles) them selfs which for most sprite based games should be a location on the rom. And of course the ‘color palettes’ (in quotes cause its the VB :D) The palette them selfs can come from anywhere ram or rom but they are generally a very small around of memory which its self can be used as a key. So an image can be located by the pair (romsource, color palette).

Getting these will be tricky, but ultimately we will have control over anytime the video ram is wrote to/ read from which is defined here in vb_vbt.cpp V810_MEMORYFETCH V810_DISPLAY_RAM; . I looked for DMA in the emulator and didnt find any cases of it, anyone know if the VB supports this? I think it would be fair to assume that only memory from Rom to VRam would be graphics we could patch. As a developer I can’t really think of many resonable reasons, other than compression which I doubt is used, to copy graphics from ram to rom unless they were generated in real time, because the ram is very limited on these machines. So all vram writes from rom could be cataloged in a table of sorts which we can then reverse for quicklookup for the graphics in rom lookup. This could all be profiled too, % directly from rom vs % from ram/registers. The worst case scenario I think is where this is hard to detect because memory is copied from rom to reg/ram then copied to vram but is still static values. If we suspect that to be the case we can pause the emulator examine the objects in memory. In those cases we could compute a hash of the graphics and swap it for some file on the harddrive. Am I missing anything else guys?

Then there is the mode7ish (assuming the VB does have something similar) kinda processing which would have to be considered, I hoping the emulator they process the colors in 16bit RGB if thats the case then we should already be covered for those algorithms if not, then they will have to be modified otherwise colors will get garbled. Which I think could wait a bit until other more basic tasks are working first.

So how would we implement this..?

I think step 1 would make the emulator dump out the objects/backgrounds from roms as it renders them. We would try to key these images as I mentioned before (romsource, color palette) and ignore other flags in memory such as location/rotation and so on.

that would be useful for two things 1 dump all images, to be patched and establish a link between the roms memory and the filesystem.

in vb_dsp.h, we would need to add a rom source value to these structures and any others that have raw graphics.

struct VB_BGMAP
struct VB_OBJ

There is also something called a world I’m assuming is a slice of graphics in 3d space maybe I’m wrong. this might need tweaking too.

//Structure defining one world from the world table
// there are 32 worlds in the world table
struct VB_WORLD

in vb_dsp.cpp, we would want to dump unique pairs of that information every time this is called: void V810_Dsp_Frame(int dNum)

step 2 would be getting colors on screen, we change the rending routines that follow V810_Dsp_Frame. but I haven’t dug that deep yet.

You’re making very many assumptions o.o

The characters(tiles) them selfs which for most sprite based games should be a location on the rom. And of course the ‘color palettes’ (in quotes cause its the VB :D) The palette them selfs can come from anywhere ram or rom but they are generally a very small around of memory which its self can be used as a key. So an image can be located by the pair (romsource, color palette).

I’ve seen enough game code (though no VB in particular) to tell you that it isn’t going to be that one location ± x bytes. Also, how are you going to display this? Is this just supposed to be an emulator patching? It started to read like that, yet somehow I got the impression that you wanted a hardware solution halfway through reading your post.

The worst case scenario I think is where this is hard to detect because memory is copied from rom to reg/ram then copied to vram but is still static values.

How else would it be transferred? You already ruled DMA out. Also, every time you rule compression out, because it’s unlikely, it usually is used. Heck, I’ve seen games that compress palettes even though the stuff is bigger than uncompressed, just because they can! Also, in some cases, you wouldn’t believe how much fun developers have to incorporate at least two proprietary formats that both do not save half as much as RLE encoding o.o!

Then there is the mode7ish (assuming the VB does have something similar)

Umm, wouldn’t affine translation cause exactly “mode7ish” graphics? I would say you would have to compute these somewhere else then, too.

Also, I’m unsure how you would want to output colors on the VB, assuming you aim for some kind of hardware solution to this.

It sounds doable, but not practicable IMO. Most people here are into it for the 3D effect, which you would have to edit as well, because it doesn’t work the same way for overlapping colors. That and we barely have any ongoing projects for hardware VB, so why build another emulator for the three games that might get an incomplete graphics pack one day?

cYa,

Tauwasser

[Yackom]

so why build another emulator for the three games that might get an incomplete graphics pack one day?

Because it would be awesome! Plus talking about it see’s how much interest there really is in it. Viewing 3d color in anaglyph isn’t that attractive I agree, but in the next few years there will be quite a few new affordable 3d displays, Hell i even have a 3d laptop sharp rd3d from like 5 years ago. I modded the n64 video emu plugin (rice’s 3d I believe) to be compatible with it! Now I can say I am one of the few (maybe only) people who ever played Mario64 in real 3d and it rocked!! The laptop is now dead but whatever you get the point 😀 come to think of it i think might still sell the pannels as monitors 15″ ones for a few hundred.

I would love to play Wario or some of these other titles in color on one of these next generation 3d displays.

Is this just supposed to be an emulator patching?

Yea it would be an emulator patch. I wasn’t intending to make it sound like a hardware mod, and I’m not entirely sure it would be really all that involved. Looking at the source code to reality boy, which is really nice btw, the dsp code is only 1000 lines which would be where most of the heavy lifting would be.

How else would it be transferred?

Thought there would be a instruction to read direct from address to address. Just checked, not the case only instruction to read memory is this one it seems. which leaves me somewhat puzzled because I thought there was a 16bit read access to the cart.

case LD_B:
tmp2 = (sign_16(arg1)+P_REG[arg2])&0x07FFFFFF;
P_REG[arg3] = sign_8(mem_rbyte(tmp2));

oh well.

Could change the read routine to cache sequential reads from the cart, and try to try to check identical sequential bytes to the vram. but that seems unreliable. but I don’t like that idea all that much though it might work and wouldn’t be hard. Worth the experiment probably.

On the other hand not doing any of that but just dealing with vram kinda simplifies the scenario a bit because it doesn’t change the fact that they are static sprites, you could easily map to some other external image file. Selecting these images to dump out would be pretty easy if you changed the the video memory viewing modes with abit of interactive ui.

• This reply was modified 14 years, 5 months ago by Yackom.

[Yackom]

OK now I’m finding the other mem read instructions… let me see what I find

Edit:
for some reason my find all ref’s was acting up anyway.

Ok found various byte,word,hword instructions for reading those arnt interseting but…

This one is. It looks like a fast point to pointer memory copy instruction. With this you can copy from rom to vram

case MOVBSU:
get_bitstr(tmp,src,srcoff,len);
set_bitstr(tmp,dst,dstoff,len);
clocks+=calc_arith_bsu_clk(src,srcoff,dst,dstoff,len);
break;

Anyway regardless of the implementation details on how to detect which graphics to replace, because there are now for sure multiple ways to do it, the concept is still very interesting

• This reply was modified 14 years, 5 months ago by Yackom.

[DogP]

Yackom wrote:
I modded the n64 video emu plugin (rice’s 3d I believe) to be compatible with it! Now I can say I am one of the few (maybe only) people who ever played Mario64 in real 3d and it rocked!!

Not the only 😉 . I used to do that w/ my shutter glasses on my CRT monitor w/ the old nVidia drivers, and now still do it w/ my dual projector setup 🙂 . I prefer Pilotwings 64 though. I’ve also got a webcam modified for viewing only IR (on top of the screen) and a hat w/ IR LEDs for head tracking (using FreeTrack).

About getting the color patches to work, I don’t think I’d go with the really detailed method you’re talking about, which would require massive amounts of detail and time to get the colors right… I’d go more w/ the Super Gameboy style where you pick a color for each shade of red, and probably also make it configurable by world (since typically a world has related stuff, same shades should usually be similar colors).

I guess a few presets would be nice too, so if half way through the game it changes, you could swap over to the other presets.

DogP

• This reply was modified 14 years, 5 months ago by DogP.

Attachments:

1. 

   1-6.jpg
   

2. 

   2-6.jpg
   

DogP, do you maintain the emulator? Whats your involvement there? I’d be interested in checking it out. I still might try to do some of the stuff I mentioned in the following weeks when I get another weekend I can screw off.

And awesome setup! at work we have a 10″ single wall ‘cave’ which is pretty nice I haven’t tinkered with it too much my self other than play quake 3 on it.

I don’t really maintain the emulator… I just made a bunch of updates for stuff I wanted a while ago, along with a few bug fixes, and occasionally do random changes/mods for myself. David Tucker (http://www.goliathindustries.com/vb/) is really the one who still maintains it. If I had some time I’d put a quick hack in for colors, but I’ve been really busy w/ work lately, and working on a couple classes for my Master’s degree, so I don’t really have much spare time. Maybe around Christmas I’ll have some spare time to play with it, if nobody else has come up with anything by then.

BTW, when you say you’ve got a cave at work, do you mean something like: http://local.wasp.uwa.edu.au/~pbourke/papers/cgat09b/ ? I keep thinking about building one of them, but although it’s immersive, without 3D it just doesn’t seem that great. Plus the software support for a fisheye projection seems limited.

I realize you could make something like that 3D with shutter glasses and a DLP projector, but this is really just something fun I like to do, which I’ve done on a very low budget (projectors were $75 each, screen was $20, polarizers/glasses were free). I don’t think a 3D dome could easily be done w/ two LCD projectors, or a CRT projector (3 projectors), because the convergence of multiple projectors on a round surface would be difficult. Really, I think my next 3D purchase will be a HMD w/ head tracking… the biggest downfall for them right now seems to be resolution and field of view. Hopefully we’ll see some advances in them if 3D ever takes off.

DogP

Hell i even have a 3d laptop sharp rd3d from like 5 years ago.

What a coincidence! I was searching for information about it today. I’m not planning to buy one, but I like reading about obscure systems. So what is it like?

Let’s continue this ‘other’ 3d hardware on another thread 😀