Shades of blue and a hidden, broken pixel that can be fixed in Soukoban Densetsu - Hikari to Yami no Kun

Let's push some boxes... err words around because it's time for another entry!

Soukoban in case you're unfamiliar, is a classic game where you walk behind boxes and shove them around a mostly enclosed area or a maze while avoiding the prospect of being trapped into unsolvable puzzles or situations forcing you to restart the area from the start.

The game was ported to numerous consoles including two Japanese versions for both the Japanese Super Nintendo / Famicom Sega Genesis / MegaDrive, and even made its way into Deadly Premonition (hahaha we will get to this game eventually!) as a sidequest for unlocking higher tier items in the general store.

First, let's start off with exploring a few unused graphical assets in this game for the sake of some box madness (ok, I should probably stop now.)

First is an unused palette for the Super Game Boy that matches the border palette. Normally it is a variation of black and white contrasts but the game's developers programmed a blue-red brownish setting but decided against using it in the game most likely because they felt it didn't show off the user's border palette creation properties as well as it was intended. This is the only game that offers a border that is centered around using system palette 0 allowing the user to set up the border to display a palette of their choosing. I guess they chose a black and white palette for the final because it makes your custom palettes stand out and they wanted focus on that feature? They could have given the option to switch between the two but that was probably more work than the developers wanted to invest, or it just wasn't a consideration at all.

Unfortunately there are a few issues with using the system palette 0 for this feature and the most notable issue is a developer oversight which I will explain and showcase later.

Load unused Super Game Boy palette

111-31B-6EE

001-3BB-6EA

Here's the lost matching border palette. There's also an oddly matching overlay appearing to fit anywhere. There is also a variation which removes the lowermost 8x8 tilemapping.

Overlaying the game screen with black attributes was not an appropriate choice for this game because the game has too varying a set of levels that would require a lot of time to compensate per puzzle and lots of space in the game's read only memory which was a premium at no less than 1mb for Game Boy Color games. Most interesting is the fact that the game's developers left in remnants from the SDK or library they using. I also found this in numerous other games including the mostly poorly ported Game Boy version Tetris Attack (it has some good music) and B-Daman Fighting Phoenix, a crossover of Bomberman and B-Daman. As you can see, the overlay looks as if it were made to show off either a platforming game or an ourside area where it is viewed from a bird's eye angle.

All that is currently known about the understanding of the SDK from my research is that it is totally unclear where the SDK originated; whether it was developed in house by Nintendo or by a different company altogether during the development of the Super Game Boy to showcase it's enhanced features such as but not limited to a library of built-in sound effects, custom music, and the ill-fated unfinished OBJ_TRN mode which would display 'scrollable' SNES objects on the screen in either 8x8 or 16x16 form overriding the static palette limitations. It is a very early SDK most likely developed in tandem with the Super Game Boy at the time, based on the fact that it has the OBJ_TRN command as C1, which in the final build of the Super Game Boy ends in a ret or return to subroutine so it wasn't implemented, but could still be accessed. I will write about the unfinished display mode at another time. 

 There are other hints that it was an official SDK designed to promote the Super Game Boy such as the "Nintendo" Super Game Boy 'SOUND' listing in the table as well as a default setting for the SNES NMI JUMP and DATA_SND definitions to perform various tasks the user could incorporate into their games on the SNES side allowing better graphics, sounds, music and a more robust interactive multiplayer mode.

The SDK appears in several games in varying revisions to suit the developer's project needs over time. It appears in a wide range of third party company developed games to name a few: Konami and Hudson.

Loads unused palette without modifying ATTR_BLK attributes (attributes black), sets a screen area overlay within specified dimensions.
001-3BB-6EA
What were they testing? This obviously looks like it could have been reserved for the title screen, story captions and cutscenes? There is also a variation which removes the lowermost 8x8 tilemapping.

Lastly, a developer oversight caused a single 8x8 pixel of the border to display an incorrect tilemapping. This renders the whole idea of allowing users to design the custom palette of the game's border. What a shame. Well, sure enough I took the liberty of fixing this issue in a matter of minutes. I fail to see how an important miniscule feature was hindered by a nefarious oversight.

Original post:

 https://twitter.com/nensondubois_/status/891869088988975105

Took 4 minutes. To fix the border, modify 0x01086D to 00 from 0C or via Game Genie code 008-6DB-D5A. The first skull is the only one that fully matches with your custom palette. So, maybe the border's ability to adapt with the player's palette was an afterthought? The skulls actually have an attribute to match the user's palette but it was never implemented.

I also made three more videos but they're lesser interesting as an afterthought. People really seem to love afterthoughts.