bad news: after extensive digging into how Wheel of Fortune (2010, Wii) loads resource files, it seems that there's no way to get it to load patch files from the memory card.
so it adds the / directory of the DVD to the searcxh path, then bundles (where the bundles are), then scripts (where the scripts are), then /Audio (where the audio files are), then it runs into a problem
Finally it checks the language (again!) and adds /Speech/$ThatLanguage to the search path.
Since getLanguage always returns "American", this'll try to add /Speech/American to the search path, and then fail because that folder doesn't exist.
Fortunately the fallback it does try, /Speech\English, does exist.
it's not my job to offer code reviews of 13 year old games but this seems less than efficient.
what if they want scripts to vary from language to language? or, hey, some of these movies have voiceovers in them... why not localize those?
The answer for scripts at least is that they implemented PackageAppInterface::getLanguage in their scripting engine, so each script can handle their own localization, rather than having per-localization scripts.
Maybe they do the same thing with movies. The movies are probably getting played by the scripting engine, so they could just switch what filenames they call for different languages
and this quickly gets really confusing because one of the first things the game loads is "[SHARED]\Localization\SharedLoc.loc.prd", which you'd think is in the SharedBundle, and it is!
which frankly is an underrated anti-reversing technique. Have multiple copies of important subfiles in separate datafiles and have complex precedence rules to determine which one gets loaded, then ignore all of them for another copy you embedded into the binary
anyway I don't think they were intentionally trying to make this hard to reverse engineer (if they were, they failed so hard), but it does mean that technically to automatically know what resources will be loaded by the game, you have to solve the halting problem
since you can't just look at the bundle files on disc and interpret what data is in them, as the existence of ROM bundles mean you have to ask the question "will this executable ever call BundleManager::mountBundle(BundleManager*,uchar*,int)?" and that's not possible to automatically know. FORTUNATELY I'm doing this manually and the behavior is deterministic.
sadly the wii balance board support classes in the engine are just leftovers from the engine's use in other games, and not proof that the developers of Wheel of Fortune (2010, Wii) were far ahead of their time in avant-garde gaming
the struct WiiControllerPack has, at offset 1480, an array of 4 KPADStatus structures.
Each of those is 250 bytes. So this array is over by byte 2440.
So where does the next member start? offset 16888.
wait. the revolution SDK defines KPADStatus about how I'd expect but then it defines KPADUnifiedWpadStatus which is a union of various things. I wonder if my debugging info is eliding some weird union nonsense going on which explains why everything is so big
me "well at least I have a bunch of types from the debug files, so I can finally figure out the types of a bunch of these untyped globals! goodbye, undefined1 PrimDrawer::bPrimBuffer[6144], let's see what you really are!"
@foone I have a build script in a p4 shelf for the game I'm working on that opts into debugging for a few key cold paths that I'm actively working on. Said modified build script also has a comment in it that says something to the effect of // !!!!!!!!!!!! FOR THE LOVE OF GOD DO NOT APPROVE THIS CODE REVIEW !!!!!!!!!!!!!!
seriously. I have complete info telling me that void WorldObject::updateVisRes(const WClipFrust &, CCheckResults); was defined on line 335 of E:\Build\WheelJeopardy\World/WorldObjectBase.h
what's a WClipFrust? that information is not in the debugging info. Go fuck yourself.
which is great because it really aids clarity of reverse engineering that every time they call vector.push_back() there's 20 lines of support code for it
either they REALLY wanted to specify that this class initializes all the floats to 340282349999999991754788743781432688640, or they accidentally included a little-endian NaN when they meant a big-endian NaN.
yeah after some dynamic testing, I think the reason this particular WStaticMesh and WSector and WPortal and WOccluder is extra cursed, with missing debug info and incorrect-invalid-floats?
It's never called. Why would it be? This is a game that basically takes place in one big room, plus a menu. Why would your map need to be split up into sectors?
arg. how is WTrackCam perfectly documented in the debug data, but the surrounding class of WCinematicCamera is not? it's not even mentioned once, not even in arguments! and it's definitely used, I found it by dynamic tracing.
the nice thing about having a scripting language is sometimes I'll see that they bind a method called "setSkippable" to ID 116 and in callMember they switch on the id and case 116 reads:
basically the stack is defined as an array of pointers to PVariable*
But they cheat, and say they have one less than they allocated, and treat the first entry as a count of how many items are in the array.
And because that's too sensible, they store the pointer to the second entry in the array, so they have to go to negative indices to get the size back when they need to expand it
so there's 25 functions here which have the exact same bytes in their body. You'd think this would be a prime candidate for link-time function-merging but I suspect there's a C++ standard reason why they can't do that:
the pointer to two different functions should probably be different
they all are "pop the top value off the VM stack and static-cast it to a different pointer".
And since types are mostly a compile-time thing, the contents of these functions end up being exactly the same. Every function is effectively just returning a void*, but the compiler enforces using them differently
I will never understand how and why CodeWarrior debugs the arguments to functions the way it does.
It'll be all:
This is a function!
It's called Foobar!
It has 5 parameters!
Parameter 1 is an int named nSlots!
Parameter 2 is a char* named szScript!
Parameter 3 is a bool named bReload!
Parameter 5 is a PVariable* named pv!
line 1038 of E:\Build\WheelJeopardy\Parser/PVMachine.cpp somehow declares two pointers named op0 and op1, which is fine, except the debug info says they are both stored in r27. At the same time.
I can find event A: a new VM is created
event B: a script is loaded into the VM
event C: a script is executed on the VM
except while the VM pointers for A and C match, they don't at all match B. I'm apparently loading scripts into VMs that were never created. and never loading scripts into VMs that I'm executing
it loads the script, creates a VM for it, then does it again. This time it doesn't need to load the script, because it's already loaded, but it DOES create a new VM. So the second VM never had the script loaded, it just grabbed it from the cache. Then it runs on the second VM
Add comment