Continuing my recent SNES work

Thursday, February 04, 2021

Where I last left off was with my discovery of the internal Wii list, and some surface conclusions. I decided to stick with that for a moment and see if I can use it to help fill in anything of the unknown parts of the game code list.

After looking at it from a few angles, I concluded that there might be something to translate from the list. Of the unreleased games in the Wii list there's a certain amount of them that were given Wii Product IDs. That amount seems to fit with the empty space in the 0x1119-0x112D (281-301) area of the list. Whats more, it makes sense for NERD to place these games first on the list over the others since being given a Product ID probably means that support for the game was done. There are not many games on the list that don't have Product IDs but were later supported. Wrecking Crew and Star Ocean are it really. And those seem to have been assigned Game Codes later on the list. I just have to keep stacking logic up like that until a picture emerges!

So I now have a handful of games and slots to fill with them. How do I figure out what goes where? Well, is not easy. In the end, I can only label these as "pure speculation" with little confidence. But I can at least use some info to make educated guesses. The info I have available is order/patterns and the decompiled code.

The established order of the list breaks down at 0x1115. Before that, the order was Wii Product ID hex style with a sub order of alphabetically region ID (D,E,F,J,P). In Hex, numbers comes before letter. 9 before A.

From the verified, and strong guessed games in this range... the order abandons all that and is very haphazard. MMX P, FF2 J, MMX2 E/P, Super Turrican 2 P, SMAS P, PI E are not grouped with their other region placements on the list, and are not placed in Product ID order. Metal Slader Glory and Marvelous are the only completely new games in this area, and show a clear abandonment of the proper hex order with 2 coming after Z.

So I had to conclude that this area is just added to as a games support was finished or it was released. But there's still a tiny inkling of a Product ID order in there. So I adjusted it and went with that. A-Z, 0-1. I figure all these games in this area were unreleased, and thus equal on release and support dates. So Product ID may take over from there.

From that, lets use pairing to help narrow it down. 0x1119/A seem like a pair, as do 0x1120/21. 0x1127-29 seem like a region trio. And 0x112C and 0x112D seem like clearly different games, but related. So with that, I figured I could place Super Bomberman 3, Prince of Persia, Super Smash TV and DQ1+2/3 in those slots, by alphabetical Product ID order. Sort of. Smash TV breaks that but makes the most sense where I placed it because it's 3 regions. Now what about the singles?

I placed those mostly alphabetically, but some are due to code indications. Indiana Jones makes sense with some code stuff, and while Combatries J wasnt in any list, it too makes sense with the code.

In the end, Kyuuyaku Megami Tensai is moved again, while 0x10B5 much earlier in the list is now vacated with no remote guess at what it is now that Prince of Persia is moved. It could be literally anything. Any of these singles, or something previously unknown. Like Super Wagon Land 2.

My confidence is low with all of this. But still, I felt it worth posting to the Game Code list. Just so people have an idea of what to test with these and help prove/disprove. I also like to have guesses in place before verification later reveal the codes game. Like a test/challenge for myself. In the past I've been wrong several times. But often enough, its not by much.

The remainder of the unreleased games probably do fit in within the range from 0x113F to 0x1159+. But theres just not enough info to make guesses. No Product IDs, and generally codes in this area do not have much for unique programing to see relations to other games. Even the verified games in this range tend to not have much for unique code, alluding to code revamps making such game specific hacks unnecessary.

After I was done with that, I moved back onto Dungeon Master again, briefly. I remembered there was a way to see more unique corrupt graphics. Which gave hope to patching it like I intended. But I still wasn't able to have any success. It's more that I cant find a single area in the ROM where specific tile data exists that I can change and see a result for immediately in game. All the addressing I have learned just keeps failing to hold up in practice. So I lose interest out of frustration. Not completely giving up, but I need to come back later with a fresh perspective.

With my options of stuff to jump around between diminishing, I started growing bored enough that I felt it was time again to start working on a different project I kept putting on the back burner. The complete VC/CC database/rom tool.

In a way, SFROM Tool kind of became part of this as it supports 4 platforms in that of WiiU, 3DS, SNESC and Switch (technically Wii too, kind of. I just never enabled code to output the file formats for that. I copied it over from another tool I made and did release, just left it disabled for whatever reason). And really, CaVE was INTENDED to be this app, but ended up becoming too Switch focused and difficult to expand into other platforms.

So I figured... IDK. Why not pool these tools and get things back on track like I wanted? I'd use CaVE as the base. I'll even retain the name CaVE, since this was its purpose, and just call it "2.0" for now. And I'll embed the SFROM tool code inside of it.

So I started a new project from scratch called CaVE 2.0. To preface the direction of this project. Switch is at the absolute lowest priority. But technically, it means CaVE Switch database management isn't completely dead for the future. Just the immediate future. Switch support is only being done as far as it satisfies my own desires/fun, and my feelings on the larger portion of the Switch community remain the same. In the future when I would release this with Switch support included, I'm not sure what my plans would be for the Full Unlock. It's complicated. It's both something entirely different and doesn't fit with the greater CaVE 2.0 project as a whole, but also renders the Switch support pointless without it. I'll cross that bridge when I come to it.

Next, sufficient tools exist for all of these platforms (except Switch now). While I do still feel they all suck compared to what they should be, they are good enough for now and thus I don't feel compelled to rush development of this project. It is something I am purely making for my own enjoyment, and is something I will take my sweet time on!

Finally, for SNESC specifically, my current aim is not to 100% replace hakchi2. As in, I don't have plans to work on the file sync/transfer stuff with it. It's too platform specific to think about right now. So at least for the first releases, this would be a half replacement/companion app. You would use CaVE to manage the databases properly, and simply use hakchi2 to transfer it over. Clunky, but good enough for now. In the future, I probably will do some sync/transfer support. Just not now. And of course, I don't care 1 shit about retroarch and BS like that. This is only for "canoe/kachikachi purists" as it were. Not about the pointless BS.

Oh. And for any that think about it and realize that Wii, WiiU and 3DS are distinctly different from SNESC/Switch in that each game is individual, while on SNESC/Switch there is a actual database to manage. How am I going to bridge this disconnect in my app? Well simply, those VCs will be managed as a database too. Just the database is a PC only thing. Not something you export as a whole. You will just export selected files. This will keep things all under 1 single UI Layout design. I'll go into details at a later time.

Now. For getting started, I figure I want to focus on the base stuff and ensuring understanding and compatibility with platforms I'm less familiar with. Base stuff being, managing display info and images. Switch is easy because I can just port code from 1.0 when I care to. SNESC is easy too. I actually knocked out basic support for its display info/images in a few hours. All the stuff for that is stored in simple formats. It's stuff like WiiU, 3DS and Wii that will be new and require work!

So first up was WiiU. I chose this first simply because I already did a little bit of work on it. Again, some disabled code for it exists in sfrom tool in the form of rpx support. But I need to go a little beyond that. The display info is not stored in the rpx file. That's in some XML files. The images are also .tga too. Not a standard format.

Thankfully SFROM Tool uses XML, so I'm familiar enough with dealing with it that reading these was easy enough. Just a little time consuming. The .tga images required some libraries though. But I eventually found some that wern't complete crap/pay to use. And was soon able to load up a WiiU image and crop out just the title screen part to display in app.

While working on that, I realized that I would need to insert text into a image for custom games. And well, the date itself doesn't exist anywhere but the image. Inserting text into an image was something I wanted to do for the Switch version of CaVE, but never looked into because I thought it was going to be too hard. I was wrong... and I regret not looking into it sooner. I hated how you couldn't tell custom games apart if you didn't use custom box art. First slight bit of wishing I didn't cancel that project. lol

As for the date, I realized that I could try something a little silly and see how it went. Reading text from an image! Silly because, in general that seems pretty advanced. And not worth the hassle. But I realized, I only need to look at 1 digit of the date, and in a fixed location. I could mock up some hackey pixel checking to figure out the date year reasonably easy enough. So I tried, and yea. It works!

So, moving on from WiiU for now. Next I tried Wii. I feel its important to ensure I get the basics understood and worked on asap for these different platforms, so I don't fall down a path again like CaVE 1.0 and limit myself from supporting these later.

Wii was a bit confusing. Each platform has inconsistent knowledge and tools available to start with. While I intend to advance understanding of these formats myself in any way I can, I don't need to reinvent the wheel. The scope of this project is large, and anything to help reduce the workload is welcome. So I'm going to be more willing to use libraries and exe's when available.

Data for Wii is not stored as plainly as NSO/Classic/WiiU, in things like json/ini/xml files. So I had to understand where it was stored... and what data was stored at all in the first place. Its embedded more in the hex as it were. And theres not much. I guess that makes sense though, as it shows that the VC formats evolved over time with what info they displayed/managed. On Wii, practically just the game name and a title screen image is all. There's a "Maker Code" which is almost like a Publisher value, but its always set to Nintendo for all games. So not the same thing. Even the game name itself is a bit weird. I've seen the style crop up here and there with later VCs, but its not exactly normal. I guess its refered to as "short name"? For example, "Street Fighter Alpha 2" is the normal/long name, while on Wii the (short) name is "SF Alpha 2".

Well, for now, after trying a few different options I ended up finding a library that will handle all I need. Extracting/inserting images and info, and compiling it all. In the end, I'll probably have to do very little work on code for this plaform. Though, its lack of info being inconsistent with later VCs will probably through out the idea of having 1 layout design for all platforms. Seeing 99% empty fields that you dont need because they exist to support Switch/Classic? Sounds like it would be ugly and confusing. So I'll just have to find a way of designing consistent but different UIs.

With Wii being good enough for the moment, all that was really left to look into was 3DS. I figured this would be the easiest besides switch/classic because 3ds was the next most recent... I was wrong.

Put simply, everything about 3DS is a confusing mess. There are a million file formats, various types of encryption, few tools that are confusing to use. Its all stuff that exists with of other VCs like Wii/WiiU, but just more so on 3DS.

It took a bit, but I was able to reduce things down to 1 main dll that as far as I know isn't distributed on its own, just with a tool called EveryFileExplorer. With that dll, I can manage most of the 3DS stuff. After a few headaches, I was able to get all 3DS files read too!

So now that I have the basics for reading files for those 4 consoles (and switch whenever I feel like porting that code over), whats next is probably going to be importing.

For Wii, WiiU, and 3DS I'm going to use a database setup where each game in the database is unpacked on import. The unpacking can be a bit confusing, and require different tools and keys and such. Its a headache that I felt was best dealt with later. I happen to already be able to unpack Wii files with my current code, but not WiiU/3DS. For those, later I'm going to have to decide what formats I want to support importing from, and what tools I need to support those.

But I may instead hold off on that a little. And focus on figuring out the code and UI layouts next. I'm in no rush to see this done, so I can take my time to do things right.

And that's where I'm at now!