Thanks for the news. If anyone has the problems listed in the news, please post here so we can try to sort this out with the debug mode
Brunni have release a new version of MasterBoy
* Finished the english documentation on how to colorize your games! *
* This version fixes a bug with sound volume when loading RIN states.
* The file list can now display up to 1024 roms.
* Added a small debug mode for the kernel version (copy the EBOOT from the Kernel mode directory to your MasterBoy directory on the PSP - this version runs significantly slower, so use it only for debugging and colorization). For people who reported me strange problems, press L+R+Triangle in the menu. It will show the available RAM. If you have the problem of save states not working after a while, please tell me how this value evolutes. Also, if this mode is enabled when going to Save states, SRAM, Save now, a message box with some information will appear, if you have the SRAM problem (not saving) please report to me the displayed text.
* Bugfixes
COLORIZATION
Spoiler!
Please register and vote Brunni 4 NEO Summer Compo 2007 (Say THANKS in other words)
Download and Give Feedback Via Comments
Thanks for the news. If anyone has the problems listed in the news, please post here so we can try to sort this out with the debug mode
Thanks a lot Brunni, do you think the recoloring option could be implemented for any other systems besides Game Boy original? I certainly wouldn't mind playing NES games with a full color pallette...
colored gameboy games... very fun.
This would require another approach and isn't evident, as NES graphics are already 2-bit. That is 4 colors (3 on sprites, + 1 transparent).
You could imagine redrawing graphics to 4-bit and adding an extended palette for a better quality but the improvement would not be major as in NES games there is a lot of "empty" or repeated zones due to the limited amount of memory, and they would not be modifiable.
It could be cool to "fill" these zones with your own graphics, but that requires modifying the maps (only possible in the ROM itself), and even in this case you would then be limited by the too restricted number of tiles.
So we are going further: it could be possible to expand the capabilities of the picture processing unit to add more VRAM, more tiles (that probably includes creating an additional attribute map such as the Game Boy Color), but it would require to modify the game ROM a lot to be able to exploit it and that would just be by far too complicated for "normal" people
Anyway the first solution is just not worth being implemented and the second would just be used by nobody
Ah, I love a coder that pays attention to bug reports in such a prompt and open manner! I will get right to work on this and see what I can dig up for you!
Results:
Fired up the Kernel Mode emulator, made my control adjustments and went right to work. The amount of available memory never flickered once I started the ROM. It started at 16,491k and stayed there through all 21 Save states and 15 Load states. At this point, I decided that I should have had the problem by then and stopped.
I then loaded up the err... non-kernel... I'm gonna call it the 'Production' version, just for ease. Fired up Zelda DX (GBC), got through 7 Saves and 4 Loads before the bug reared its ugly head again. I restarted the emulator and went to Sonic 2 (SMS). 7 Saves and 8 Loads later, same thing.
The two Save State file sizes are slightly different.... Sonic 2 was 7887 bytes per save (total of 55,209 bytes over the 7 saves) and Zelda DX is 7224 bytes per save (50,568 bytes total).
So it appears that the bug is limited to the 'Production' version, and not the Kernel version. If there's any other info you'd like me to dig up, I'll be happy to continue lending my assistance. Until then, I'm just gonna run the Kernel version at 333 MHz.
Another cool release from Brunni, always happy to see his releases
I don't want to be irritating... but you should consider what I wrote you in the email Brunni (I suppose you know who I am )
Just ask some opinions. You have nothing to lose by just asking people's opinion about it.
It's not wrong doing something like it. Everyone wants it. Everyone will love it.
And no, you won't be remember as the developer who did it just to do it (and impress, or whatever).
You'll be remember as the developer who made the one and only emulator, through other masterpieces
And of course I suppose their original developers will be happy, too
Bad news, Brunni.... I started getting the error today on the Kernel version, too. It took MANY more Saves and Loads (I stumbled my way through two full dungeons and aimless wandering around the overworld in Zelda DX. Several hours' worth of play.) than the 7 the 'Production' version managed, which is likely why I didn't run into it last night.
The Total RAM used after the bug popped up was no different. Still 16,491k.
Hey Brunni,
I have a question and possibly suggestion for you regarding the "[Unsolvable] Cases" section of your colorization document.
Since a lot of Game Boy games use a "blank" tile for the sky of a level as well as doors and "empty" space in other background objects, it's impossible to colorize the sky of a level without messing up the other objects.
What if Masterboy were to look at the level's map as well as the tiles currently loaded in the VRAM, and color a certain tile with different palettes depending on which other tiles are next to it?
For example:
I want to color the sky blue in Kirby's Dreamland. Doing so, however, will also color the door of this room blue because they both use tile +133 (as shown in red).
I, however, want this tile to be white when it is used as a part of the door. Whenever tile +133 is being used to draw a door, it will always be located beneath tile +227 or tile +228 (outlined in yellow and purple).
If it were possible to tell MasterBoy to always color tile +133 blue EXCEPT when otherwise specified, and later specify that tile +133 should be white when it is underneath tile +227 or tile +228, it would allow for both a blue sky and a white door.
If Masterboy could check for which tiles are touching a certain tile from above, below, or its right or left sides, it would greatly improve the colorization features MasterBoy provides.
Would this feature be possible implement in the next version, or would this type of checking slow down MasterBoy's Game Boy emulation too much?
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks