Could the animation speed problems somehow tie in to the fact that Sonic Adventure was originally intended to be a 60fps game and then capped at 30? Though you'd think that would make animations twice as slow... but who knows what it might've done to the game's internal timing system. Framerate drops in these early 3D Sonic games always did weird things to game logic, and I'd assume that only made the collision detection worse in the Dreamcast version.
This is really difficult for me to tell but from what I can see, the final version animates too slow rather than this animating too fast. Given that these preceed a section where the wind is so powerful that it can blow characters off the ground, you'd expect these bits to animate quickly. Come to think of it much of Windy Valley seems a bit like this. In the first few minutes it doesn't even look windy - I'm not sure if that's the point, I.e. the wind is meant to pick up, but it makes you wonder why they bothered animating some of these things given that they move so slowly. EDIT: Then again I've just caught up on some old prototype footage and it seems to animate at about the same pace. p.s. did we know about this footage, where Segata Sanshiro turns up and they play the theme song live with Japanese lyrics?
O_Raft! This was taken near the end of Act 3 (before the part with the huge ramp that goes down into the valley). Remember how there was a huge gap between the bottom platform and the start of the ramp? It looks like it was once populated with these hovering platforms that you can use to walk on. I recall that the wind currents (that can carry you) are also loaded around here too. This object also has multiple models that you can select by passing a parameter in the set file, they all float up and down the same way since they use Raft's code though. I don't know if I implemented it correctly though. Even though the object animates and you can walk on it, you don't move with the object as it hovers (you just stay in one place in the air). This could be just because the object is unfinished, since I found another object which is considered one of the 'static' ones that has a base with collision but you fall through the top if you jump on it: I forget what this object is called, but you can climb and rub against the base of it but you fall through if you jump on top of it. I'm still unsure what we could do to get textures loaded in this stage. I did find the table of pointers to all the texture files in 1st_read, but there aren't any null places I can sneak in a pointer or something. Although I don't know how the game gets the equivalent texture file for the stage with code (could it be using the stage number as an index?). I also don't know how you could add a file to a gdi image, but I'd imagine you would have to edit IP.BIN somehow.
To add files, just add the file and rebuild the GDI. Nothing special needs to be done to add or remove files from the disc. If you run out of space, GDIbuilder will tell you when there isn't enough room. That's unlikely, you should have plenty of space to add whatever you need. So regarding textures, it actually has to be told what file to load? I was hoping they'd automatically look for something that matches the stage name and that we could just take Dude's textures, shrink where appropriate, convert to PVR and repack them. It's a shame it doesn't work like that? How about replacing one of the existing ones? It's not like the other levels need to work if your goal is to fix this one.
That's awesome. I was expecting to fight a bit with the image format in order to add new files but it looks like this will be much easier than I thought. The game's main executable (1ST_READ) only looks for files that have been included in the AutoDemo, but the stage files (which were compiled a month before the main executable was compiled) have references to files that don't exist. STG02 for instance references tomado_00#.pvr which I assume are texture files for the Tornado but no such file is referenced anywhere in 1st_read. The stage files also include the list of texture names for each stage or object. 1st_read has a table for the stage texture files in a table at 8C191050 which includes a pointer to the name of the texture file and a pointer to where the list of textures in that specific stage file are located. There's nothing for Windy Valley, not even a blank space for where it used to be. I'd have to find someway to extend the table to include the file name of the texture files I'd have to add along with the pointer to the stage's list of textures, and then figure out how to get the game to jump to it in the table when it loads Windy Valley. I can't do this without doing a full disassembly of 1st_read that can be assembled. And then I'd have to kinda rebase every pointer I found to their new locations in the newly edited 1st_read file. That's just a ton of headaches waiting to happen. So I think replacing one of the entries in the stage texture file table in 1st_read that already exist to the newly added file (or edited file) would be more ideal. I would just have to figure out how to get the game to jump to the correct spot in the table when it loads the stage up.
Those are some great discoveries! The wind raft things in particular look like they would be really cool!
I got some more objects loaded in the game. More bad gifs with red and green corrupt textures just in time for the holidays. Misc Prope 1 2 3 (Act 1 Propellers) Oddly enough these have no collision. I'm not sure if it's an error on my part, but it'd make sense to not have any because you'd run into a lot of them. Prope C (I think...): This one does however. You can walk against it but you wont get hurt. It sure does look like it would though... Dome 1: I have no idea what's going on here. The object itself has no collision save for this rotating cylinder in front. I believe I must've done something wrong but I can't be sure. There's a call to a pointer near the very end of the object's subroutine that I couldn't find the pointer of, which is definitely meant to do something to the object if you walk away from it after it loads (most likely a function to delete the object from memory) but I couldn't find it. I just replaced the pointer with something that wouldn't cause a crash and it seems to work okay (although the subroutine I'm pointing to now causes the words "PUSHOUT" to print on the screen quickly while you walk away). Another thing that came to my mind was the game's object limit when loading the entries from the SET file. I'd have to somehow find a way to lift that limitation so that all the objects in the first act will load up. I found the subroutines that load the stage's binary file, set file, and cam files as well as the subroutine for specifically loading the set file but I don't see anything that would prevent it from loading all the entries in the file. I was looking on MainMemory's disassembly of the SADX PC port and found the same subroutine I was looking at, but couldn't find anything that would prevent a certain amount of objects from loading up...
It's been a while. A couple things before I get into some of things I discovered recently. The folks over at TCRF have finally touched up on the research article for this prototype here. A huge chunk of what's been posted in this thread has been mentioned there so it all doesn't get lost. There's even some stuff that I wanted to do that I haven't gotten to, such as actual level geometry comparisons with some of the stages that don't load in game (like Sky Deck and Lost World). The prototype (along with Orengefox's other releases) have been archived on Hidden Palace. :D Also on the topic of research, if you recall, the game actually has some localization files in this build for an English version of the game. The game didn't really get localized until Sonic Team USA was formed some time in 1999 (I think), so I'm not sure who was responsible for localizing this prototype. However, it seems that an English version of a prototype eerily similar to this Autodemo was actually featured in the states a month before it's release in Japan and almost a whole year in the USA. Gamespot writes of an event called "Sega Gamer's Day 1998", which occurred on November 5th, 1998. They mention that while Sonic Adventure was featured at the show, it was specifically a later revision than the one featured at TGS and didn't seem playable. Gamespot writes: It's difficult to determine if the entire game was a whole Auto Demo or if it was just played by the employees hosting the event. Regardless, it sounds very similar to the AutoDemo we have and it's currently the only known event of the game being featured in the states before it's original release in Japan. Thanks to TheRedEye, we actually do have screenshots that were given out to the press in relation to this event. I don't think it's indicative of what was playable at the event though. If anyone can find more information about the build that was featured at this event please feel free to post. Finally, I've been meaning to look at the files featured exclusively in the AutoDemo. There are a few interesting files that don't seem to appear in any version of the final game for various reasons. Let's take a look at a few (comparing with the original Japanese release): 32ASCII.PVR Textures for the font used for the boss battles I think. I don't remember where they eventually moved the font textures to, probably to the texture files for the stage objects. ADV00OBJ.PRS Object code/data for Station Square. I think this got merged into ADV00.PRS for the final. ADV02OBJ.PRS Object code/data for Mystic Ruins. I think this got merged into ADV02.PRS for the final. ADVEC02.PRS Textures for Egg Carrier Exterior (Transformed: Rear Deck). These files were renamed to include an underscore for the final, but are otherwise slightly different in comparison. ADVEC31.PRS Textures for Egg Carrier Interior (Bridge). See above. ADVEC33.PRS Textures for Egg Carrier Prison Room. See above. BGM.AFS Contains all the music for the demo. The AutoDemo keeps all of it's music in one file while the final versions keep everything separate. Maybe this was done to keep load times down? CAM0B00S.BIN An empty camera file for a possible cut stage. Interesting thing to note is I think every set/cam file in the final use decimal numbers for the stage number part in the file name, but this file uses hexadecimal instead. This file has the same date as the cam file used for the test stage (which is also blank). If the hexadecimal part of the filename actually just reads as CAM1100S.BIN, it could be possible that it's meant for an actual cut stage from the game (since all versions of the game skip STG11, and nothing makes reference to it, whatever it is). CAM0300.BIN A camera file for the Twinkle Cart segment of Twinkle Park. The file name indicates that this is more general and not for any specific character (even though only Sonic can go to the Twinkle Cart segment in the final game). The prototype actually does have a CAM0300S.BIN, which is used by the game if the stage can be loaded. The date for this file is July 30, 1998 (the one that is unused), the used one is dated September 18, 1998. The differences between the two are kinda minimal, I'm not sure what they specifically are though. CAM0700.BIN A blank camera file for the Tricky Maze segment of Lost World, dated July 30, 1998. CAM0803S.BIN A camera file for Ice Cap Act 4 (Big's version of Act 2). The interesting thing to note is that the file name indicates that this is specifically for Sonic. This file was worked on later than Big's camera file, so is it possible that Sonic could've been playable in this stage at one point? CAM1004S.BIN A camera file for Final Egg Act 4, for Sonic. A bit of trivia, the Final Egg stage in the Auto Demo actually used to contain the three Practice/test stage maps (probably to test the stage specific objects at one point). The AutoDemo even includes the object layout files for these Final Egg acts, which are identical to the set files included for the test stages. The interesting thing to note here is that the camera file for Act 3/4/5 are all identical. CAM1003S.BIN still exists in the final, but I don't think is used. It's possible that this file could be a possible camera file for the first test stage itself. CAM1005S.BIN A camera file for Final Egg Act 5, for Sonic. See above. CAM1600K.BIN A camera file for the Chaos 2 fight, for Knuckles. I don't think the final uses a camera file for this stage in the final because the object itself is programmed so that the camera is always focused on Chaos, so the need for a camera file was scrapped. The camera file itself is blank too. CAM1600S.BIN A camera file for the Chaos 2 fight, this time for Sonic! Chaos 2 is an exclusive boss fight for Knuckles. Maybe Sonic could fight Chaos 2 at one point? CAMAL_RACES.BIN A camera file for the Chao race fields. The final build uses two files instead of one for the race fields. CAMEGM1S.BIN A camera file for the Egg Hornet boss battle, for Sonic. Like the Chaos 2 boss fight before, the camera is always fixated on the boss so this made the need to use a camera file for the stage unecessary, so this file was removed from the final. CAMROBOS.BIN A camera file for the Zero boss fight, possibly for Sonic for some reason? The final game calls the stage file for this fight B_ROBO. Again, the camera file is unecessary because the game is programmed to always follow the boss. This file is blank. CAMSBOARDS.BIN A camera file for the Sand Hill, for Sonic. The final build uses two files instead of one for this field. CAMSETSS00S.BIN This one is strange. This is apparently a camera file for Station Square City Hall (Sonic), and it actually has some camera data. This file is dated September 21, 1998. However, the final doesn't have anything called CAMSETSS##S. The final uses CAMSS##S instead. The AutoDemo has both CAMSETSS##S as well as CAMSS##S, for some reason. CAMSS##S in the Autodemo is much older than CAMSETSS##S, and contains nothing but blank data for each segment. I don't know which is used in the AutoDemo though. CAMSETSS01S.BIN A camera file for Station Square Casino. See above. CAMSETSS02S.BIN A camera file for Station Square Sewer. See above. CAMSETSS03S.BIN A camera file for Station Square Station. See above. CAMSETSS04S.BIN A camera file for Station Square Hotel. See above. CAMSETSS05S.BIN A camera file for Station Square Twinkle Park. See above. CAMSHTS.BIN A camera file for Sky Chase, for Sonic. This build contains the camera files for both acts of Sky Chase for Sonic, and they are identical to the camera files used in the final. Although I doubt the came uses the camera files, since this part of the game is on rails (could be wrong though). But for some reason, the prototype used to have one camera file for Sky Chase, which is blank. DEMO_TITLE.PRS Title screen used for this demo. DROP.PRS A water drop animation. I don't know where this could've been used, if it was used at all in the final. Possibly used for Chaos, perhaps? E102ITEM.PRS Textures for Gamma's gun. This is apparently in a separate file, while the final build has these textures part of Gamma's character texture file I think. Is it possible that maybe Gamma's gun was an item that was meant to be acquired originally? EVF0800.BIN A decompressed event file. The final game compresses these and gives them a different file name instead. EVF0801.BIN See above. EVF0802.BIN See above. EVF0804.BIN See above. (Yea, the build doesn't have a EVF0803.BIN, which probably would've been a demo for Knuckles since it's missing from this build) EVF0805.BIN See above. EVF0806.BIN See above. GOAL_A.PVR The mysterious old left over texture. What this was meant for in anyone's guess. GOAL_B.PVR The mysterious old left over texture. What this was meant for in anyone's guess. K_TUTORIAL_USA.PRS A translated version of K_TUTORIAL, the demo exclusive in game tutorial for Knuckles' game play. The file doesn't exist in the Japanese final, however, K_TUTORIAL which is still technically unused still exists in the Japanese final for some reason. KEY0502OO.BIN An unused short alternative to KEY0502.BIN, which is used for demo playback. This build uses KEY0502, which was made on Oct 8th 1998. KEY0502OO was made Oct 2nd, 1998. I don't know what KEY0502 correlates to. I could load this up and see what this is, but I'd prefer to run it on real hardware since most emulators desync the demo playback due to badly emulated timings. LAND1800.BIN An uncompressed LandTable for the Chaos 6 battle. B_CHAOS6 (which includes the landtable as well as the programming and object models) exists in this build, so it's unclear why this file exists in this build as it only contains the geometry for the stage itself, no programming or object models. This file actually predates the B_CHAOS6 featured in this build by a few days, so this might be different. LM_CHAOS7.PRS A texture file for the Perfect Chaos boss fight. This file is much smaller in comparison to the final's LM_CHAOS7_0.PRS. I'm not sure why the file name was given an additional number at the end in the final though. The texture file, even though it's dated the same day as B_CHAOS7.PRS (which is also featured in this build) doesn't actually apply correctly to the level geometry for some reason... MISSION_A_US0.PVR A localized mission run down exclusively for the demo (used if you enable the HUD in game). MISSION_A_US1.PVR See above. MISSION_A0.PVR See above. MISSION_A1.PVR See above. MISSION_B_US0.PVR See above. MISSION_B_US1.PVR See above. MISSION_B0.PVR See above. MISSION_B1.PVR See above. MISSION_E0.PVR See above. MISSION_E1.PVR See above. MISSION_E102_US0.PVR See above. MISSION_E102_US1.PVR See above. MISSION_K_US0.PVR See above. MISSION_K_US1.PVR See above. MISSION_K0.PVR See above. MISSION_K1.PVR See above. MISSION_S_US0.PVR See above. MISSION_S_US1.PVR See above. MISSION_S0.PVR See above. MISSION_S1.PVR See above. MISSION_T_US0.PVR See above. MISSION_T_US1.PVR See above. MISSION_T0.PVR See above. MISSION_T1.PVR See above. MOVIE.PRS An older compressed version of MOVIE.BIN that predates the file by 3 days. The decision to use an uncompressed exectuable to play the .SFD movies must've been done at the last minute. Oddly enough, the executable mentions the file names of the .SFD videos that can be played. MOVIE.BIN mentions the two .SFDs featured in the AutoDemo, MOVIE.PRS mentions two .SFD videos that are probably the same videos but given a different file name. The file names MOVIE.PRS uses are SNTM_450.SFD and SAOP600.SFD. MRACE_EGGMOBILE_1.PRS I believe this is the texture file for Eggman in Tails' Speed Highway racing stage. The final doesn't have the _1 at the end of the file name. But other than that, there are some small differences between the two texture files. OBJ_EC_AB.PRS A texture file for some segment in the Egg Carrier field. I'm not sure what this belongs to. OBJ_EC_C.PRS See above OBJ_EC10.PRS A texture file for some segment for the Egg Carrier's exterior fields. This was probably merged into OBJ_EC00.PRS for the final to cut down on load times. OBJ_EC31.PRS A texture file for some segment for the Egg Carrier's interior fields. This was probably merged into OBJ_EC30.PRS for the final to cut down on load times. OBJ_EC33.PRS See above. RIPPLE.PRS Possibly used with DROP.PRS, but it looks like a rain drop ripple possibly used in the Chaos 0 boss fight somewhere. SAKANA.PRS Model and possibly some coding for the sea bass, used in Big's stages. I forget where this and the models for the other fish are stored in the final. SAOP1006.SFD The opening movie. The "1006" part of the file name refers to the timestamp of this file. SET0803S.BIN As mentioned before, Sonic has a camera file for Act 4 of Ice Cap (Big's stage). He also has a unique object layout/set file for the stage as well. This file was removed from the final. SET1004S.BIN As mentioned before, Final Egg used to contain the three 'Practice' stages (the test levels). These are the set files for all three. Oddly enough, the game duplicates the object layout for all three test levels. This as well as the other files match SET0000S.BIN, but I believe only the object IDs were changed between the two (to reflect object list changes possibly?). SET1005S.BIN See above. SETAL_RACES.BIN A blank set file for the Chao race fields. This was split into two files for the final build. SETEC31E.BIN A set file for the main area of the Egg Carrier, exclusive for Gamma. This file doesn't exist at all in the final, probably because every character uses the same set file as Sonic (SETEC31S.BIN). This file was updated in September, while all the other set files were updated in August for some reason. SETROBOS.BIN A blank set file for the Zero boss file. The file name was changed to SETZEROA.BIN in the final. Oddly enough, while this is for Sonic as well, there does exist a SETZEROS.BIN in the Japanese final build for some very bizarre reason. SETSBOARDS.BIN A much smaller Sand Hill set file for Sonic. The final uses two files (for Sonic and Tails I think). SETSHTS.BIN A generic set file for Sky Chase. I already detailed the weirdness of this file before. This was instead split into two files, one for Act 1 and the other for Act 2. START_A.PVR More mysterious texture files from 1997. START_B.PVR See above. STLOGO2.SFD Sonic Team logo video. TARGET_HP.PVR Boss 'Target' HP bar texture (I think this was merged somewhere else in the final). TARGET_HPBAR.PVR See above. USA_SOUSA_A.PRS A localized "How to Play" for Amy. USA_SOUSA_B.PRS A localized "How to Play" for Big. USA_SOUSA_E.PRS A localized "How to Play" for Gamma. USA_SOUSA_K.PRS A localized "How to Play" for Knuckles. USA_SOUSA_S.PRS A localized "How to Play" for Sonic. USA_SOUSA_T.PRS A localized "How to Play" for Tails. Also, I'm still putting off the Windy Valley restoration on hold for now since I'm busy working on Hidden Palace stuff now. I hope I can get back to it soon... I think I'm finally going to tackle the cutscene voice files next, so stay tuned for that. EDIT: Here are the unique Event ADX files from the Auto Demo. I extracted the .afs files from the Japanese final and the AutoDemo with puyotools and used Total Commander to compare the two builds based on their contents (to find duplicates that appear in both versions). Whatever was leftover is unique to the Auto Demo. I'm not too familiar with the Japanese dialog, but I recognized a few differences (like the female announcer featured in Final Egg/Station Square lacks the reverb effect). Feel free to check it out.
These screenshots are just some of the images Sega released when Sonic Adventure was first announced at the Tokyo International Forum. We have a collection, and if you have a look, every magazine scan before a certain date uses them. As for documentation - Sega Gamer's Day 1998. Add to it
B32ASCII.PVR/B32ASCII_J.PVR In the final, 'Q' is replaced with '?' (delta), 'X' is replaced with '?' (epsilon), 'q' is replaced with '?' (zeta), 'x' is replaced with '?' (alpha) (???), and '?' (roman numeral two) in B32ASCII.PVR/some japanese character or something idk in B32ASCII_J.PVR and '?' (beta) are added to the end.
I believe this is the character ? ("kai" or "aratame" idk, meaning "revised"), used in E101mkII's name in the Japanese version. According to supplemental material, ZERO's internal codename is E-100?, so that's probably where the alpha was meant to be used.
/>/>/> I got Windy Valley Act 1 to load up all the objects with original coding in the AutoDemo. [youtube]http://www.youtube.com/watch?v=7aq1gT6bcQc[/youtube] I also finally have Windy Valley Act 3 running as it should too. [youtube]http://www.youtube.com/watch?v=iUL_It62j7A[/youtube] I figured this would be a bit better than using animated gifs, since now all the used objects have been fixed for these two acts. :P Now finally, here are a couple of things I noticed while playing Act 1 with all the objects. First of all, yeah the game is that slow with all these objects, it's not the emulator at all. On top of all the objects being displayed at the same time, the game actually uses a very sophisticated version of the "PuWind" object (the object that lifts the player off the ground and levitates them over pits with leaves). The object itself is much more dynamic with it's leaf particles and will actually stay attached to the player for a short while while in the air and even a few seconds after walking away. A very cool effect that probably got simplified for the final for causing slow down. Here's another object called Sirusi1: Act 1 especially has tons of objects with animations and density. Most of them don't have collision probably because Sonic would run into them a lot. This is WCWIND I think. It does pretty much the same thing as it does when used in the final. I have no idea what it's used for as it's arrangement on the stage is random and it doesn't really do anything besides twitch in place... Tanpopo! This is also in the final game but I think the effect is a bit different here if I recall. I restored the three bridges in act 1 as you can see from the video, but for some reason the model is missing (probably due to the missing textures). I also still can't find the path data used for some of the ramps. Sonic unfortunately still crashes when bouncing on the trampoline so Knuckles/Tails work best for the two levels. Sometimes the game will crash when you punch those rhino bandiks with Knuckles. I had to use the debug mode because of the lack of textures. Also, notice how the springs are a bit too big and sometimes clip through some objects in Act 1. This was probably made around the time they were using the older Sonic Jam type model for the spring. There are still a few objects that go unused in any act I believe that still exist in this build of Windy Valley: 16 - BLEAF 3d - Pot01 3e - Pot02 53 - TakoW 55 - Dome2 56 - Dome3 6e - Wele 72 - EE103 I didn't bother with fixing these yet. But it's interesting to note that TakoW is the tornado, which for some reason isn't referenced at all in act 1's set file. Importing the objects wasn't as bad as it seemed at first since many objects take advantage of the same functions. To double check with what I had, I just took the bytes of the bad pointer from stg02 and searched through all the uncompressed stage files from the AutoDemo to find the pointers in other nonplayable stages. I disassembled the other nonplayable stages that I found the bad pointer I was looking for and looked to see which objects were looking at them. Since the game's other levels aren't drastically different in terms of loadable objects, I used this fact to find the equivalent pointers to the functions used in the final NTSC-J release. Once I found the equivalent working pointer in the final NTSC-J build, I then searched for other references to the bytes of this pointer in the uncompressed stage files in the NTSC-J build that were playable in the AutoDemo. I think disassembled that particular stage file in both the final version and the AutoDemo, compared the two, found the similar function call which led me to find the correct pointer to use in the AutoDemo. Very convoluted, but it worked quite well. As for getting the first act of Windy Valley to work, this took a bit more effort. The problem with every build of Sonic Adventure (afaik) is that the game is hard coded to only have enough memory space available to work with anything more than 0x8000 bytes. The other problem is that loading the data from the stage set file and assessing the data from that file are different things. Here's how it works: 1.) The game has a function at 8C07CF60 in 1ST_READ with a switch statement that will jump to branches that load all the files for that particular stage at once. The function will store the stage file 'keys'/offsets, which are really nothing more than memory locations in RAM to store the files. Windy Valley's jump in the table is at 8C07D076, and will first load the stage file, then all three stage set files, plus all three camera files for each of the three acts. 2.) When loading both the camera and set files, the game uses the function at 8C07CD60 to load/release the data stored when reading the files. According to the values passed to the registers before branching, CB68000 is where the first act's set data is stored, followed by CB70000 and CB78000 for acts 2 and 3. The game will load the camera data for each individually act starting at CB50000 for act 1, CB60000 for act 2, etc. The problem with this is that the game carves out only 32kb of memory per act for each set file, or roughly 1023 objects. Act 1 has 1813 or so objects. 3.) However, when the game calls 8C5B3292 within this function, it will actually copy every byte of the set file into memory! The problem though, is that as soon as the game returns from the branch to load the first act's set file, it'll immediately store the next act's set file to CB70000 overwriting any extra bytes that were stored previously. The game actually hard codes where the data for each set file is stored in ram for each zone in a table at 8C18FAC8. So in short, the stores the first acts set file at CB680000, and then half of it gets overwritten when storing the data for the second act at CB70000. The solution to this is simple, we just have to double the amount of each memory region so that the game can actually load everything without overwriting the first act's set file. In 1st_read, I basically changed every single reference to the following bytes (in little endian of course): 0CB68000 left alone 0CB70000 to 0CB78000 0CB78000 to 0CB88000 (this has to be changed first) Unfortunately, that alone wouldn't let the game load up all the objects. The table that stores the memory locations of the individual set files for every stage isn't actually used by the function that loads everything in memory. The table is actually used by the game to manage the objects themselves when transferring/copying the set data to another section of memory that can be manipulated by the game directly (for whatever reason). This function (located at 8C073094), actually manages the memory region that's set up for the object space. This function is programmed to only work with h'3FF (1023) objects at once (resulting in the game only copying the first 1023 objects that were loaded up by the function that loaded the set data itself into memory that I mentioned before). This value is located at 8C0730C2 in 1ST_READ, and has to be changed to h'7ff in order for the game to attempt at reading all the extra objects. However, changing this value to h'7ff causes the game to crash when act 1 is loaded up because the game will actually end up overwriting the other data stored in ram. Because of this, I had to relocate the address in which the game will copy the set data so that it's in a location that has more room for all 1813 objects. In this build, there are 4 locations in memory that are used to reference data stored by the previous function. 8C78EA40 (holds the pointer "0cb68000", or the address that points to the number of objects in the set file, or the first unsigned long in the set file) 8C78EA44 (holds the pointer "0cb68020", or the address to the first object in the set file in 0c space) 8C78EA48 (holds a copy of the unsigned long of the total number of objects in the set file) 8C78EA4C (holds the pointer to the first object in the 8c memory space) I dumped the ram/vram with Demul 0.49 while in a level and looked for a section of ram that can hold the bytes for all 1813 objects. I ended up using 8C7C92A0, since it looked like that the game didn't bother to use all of it under any circumstance. So I adjusted the four pointers mentioned in 1ST_READ that I mentioned above to the following: 8C78EA40 to 8C7C92A0 8C78EA44 to 8C7C92A4 8C78EA48 to 8C7C92A8 8C78EA4c to 8C7C92Ac To recap, the only changes made to 1ST_READ.BIN in the AutoDemo to fix the first act of Windy Valley so that all objects could display were the following byte changes: 8C78EA40 to 8C7C92A0 8C78EA44 to 8C7C92A4 8C78EA48 to 8C7C92A8 8C78EA4c to 8C7C92Ac 0CB70000 to 0CB78000 0CB78000 to 0CB88000 (this has to be changed first) h'3ff at 8C0730C2 to h'7ff All of that, plus the bad pointer restoration work I've been doing up to this point for all the objects bring the results you see in the videos above. />/>/>/> Unrelated, but another thing to note while I was looking to the game is that the game will load an additional binary file on a certain test stage called SAKANA.BIN. I believe this just contains object code for some fish for Big. So I guess the test maps could be used to test Big's fishing at one point.
I've been thinking of how I wanted to restore the textures for both acts, and I think there's a good way to do it. First, let me explain how I think the game handles its texture files. The game is a bit of an inconsistent mess when it comes down to loading texture files and it took me a while to at least understand a little of what's going on. The game keeps track of its textures for the stages, objects (not counting player/common objects), and backgrounds in three different ways. The game contains a huge table of pointers of what I can best describe as "miscellaneous" textures for individual adventure fields and stages at 8C190DC0 in 1ST_READ. The table contains a pointer for a much smaller/specific table of pointers for each stage in the game (in order of level ID). The pointers in the big table can actually point to smaller tables that exist in both 1ST_READ and a particular stage file. The smaller tables consist of a series of two kinds of pointers: first a pointer to the file name of the texture file, followed by a second pointer to the address of the head of the texture list for that file. The latter pointer can either point to a location of a head of a texture list within 1ST_READ or the stage file itself (8c base addresses vs c9 base addresses). This depends on either or not the pointer is for a texture list for stage objects (which very often have the texture list in the stage file itself), or if the texture file is for something more commonly shared between all stages (like the textures for the flickies and certain enemies that appear in more than one stage). Here's an example of a small miscelaneous texture table, which is for Red Mountain in the AutoDemo: *note anything given a name for the pointer itself is located in the stage file for Red Mountain Code (Text): seg001:8C190828 TexHeadMiscTable_Stg05:.data.l aObj_mountain ; DATA XREF: seg001:8C190DD4o seg001:8C190828 ; "OBJ_MOUNTAIN" seg001:8C19082C .data.l Texhead_OBJ_MOUNTAIN seg001:8C190830 .data.l aE_saru ; "E_SARU" seg001:8C190834 .data.l off_8C568830 seg001:8C190838 .data.l aSupi_supi ; "SUPI_SUPI" seg001:8C19083C .data.l off_8C575638 seg001:8C190840 .data.l aUni_c_unibody ; "UNI_C_UNIBODY" seg001:8C190844 .data.l off_8C573CF0 seg001:8C190848 .data.l aE_bomb ; "E_BOMB" seg001:8C19084C .data.l off_8C571590 seg001:8C190850 .data.l aTogeball_togebal ; "TOGEBALL_TOGEBALL" seg001:8C190854 .data.l off_8C571D58 seg001:8C190858 .data.l aMountain_steam ; "MOUNTAIN_STEAM" seg001:8C19085C .data.l Texhead_Mountain_Steam seg001:8C190860 .data.l aMountain_e104 ; "MOUNTAIN_E104" seg001:8C190864 .data.l Texhead_Mountain_E104 seg001:8C190868 .data.l aMountain_mexplosion ; "MOUNTAIN_MEXPLOSION" seg001:8C19086C .data.l Texhead_Mountain_MEXPLOSION seg001:8C190870 .data.l aYougan_anim ; "YOUGAN_ANIM" seg001:8C190874 .data.l Texhead_Yougan_Anim seg001:8C190878 .data.l aZou ; "ZOU" seg001:8C19087C .data.l off_8C14F3DC seg001:8C190880 .data.l aGori ; "GORI" seg001:8C190884 .data.l off_8C1543B0 seg001:8C190888 .data.l aLion ; "LION" seg001:8C19088C .data.l off_8C152644 seg001:8C190890 .data.l aOum ; "OUM" seg001:8C190894 .data.l off_8C13E2B0 seg001:8C190898 .data.l aMogu ; "MOGU" seg001:8C19089C .data.l off_8C14C1E0 seg001:8C1908A0 .data.l aK_tutorial ; "K_TUTORIAL" seg001:8C1908A4 .data.l Texhead_K_TUTORIAL seg001:8C1908A8 .data.l 0 seg001:8C1908AC .data.l off_8C50ABC8 seg001:8C1908B0 .data.l 0 seg001:8C1908B4 .data.l off_8C50AB74 seg001:8C1908B8 .data.l 0 seg001:8C1908BC .data.l 0 Notice how in this smaller table, it starts off with a reference to the texture file for the stage objects first, then goes on to reference the textures used by the badniks on this stage then followed by your animal friends, then ending with some other stage specific files. The second way this game works with its texture files is how it loads the texture files for the stage itself. The data for this begins with a table at 8C191158 in the Autodemo, which includes pointers to a series of four bytes + a pointer to another table much like the smaller table above. This table (which begins at 8C190FA8 in the AutoDemo) contains a series of two pointers that point to the name of the texture file for the stage followed by a pointer to the head of the texture list for that file. Out of everything I know so far, the only thing I still don't understand at all is the significance of the four bytes that precede the pointer. This is what I'm looking at: Code (Text): seg001:8C191050 StageTex_Beach01:.data.b 0 ; DATA XREF: seg001:tbl_stagetexturefileso seg001:8C191051 .data.b 1 seg001:8C191052 .data.b 1 seg001:8C191053 .data.b 0 seg001:8C191054 .data.l StageTexPtr_Beach01 seg001:8C191058 StageTex_Beach02:.data.b 1 ; DATA XREF: seg001:8C19115Co seg001:8C191059 .data.b 1 seg001:8C19105A .data.b 1 seg001:8C19105B .data.b 0 seg001:8C19105C .data.l StageTexPtr_Beach02 seg001:8C191060 StageTex_Beach03:.data.b 2 ; DATA XREF: seg001:8C191160o seg001:8C191061 .data.b 1 seg001:8C191062 .data.b 1 seg001:8C191063 .data.b 0 seg001:8C191064 .data.l StageTexPtr_Beach03 For instance, I don't know what the significance is with the "0110" that comes before StageTexPtr_Beach01. The only two bytes that I can tell with absolute certainty is the second byte, which refers to the internal stage number in the game, and the first byte which correlates with the act number for the stage. But I don't know what the other bytes are for. Finally, as far as backgrounds are concerned - this is dependent on the stage file itself. In some cases, the backgrounds can be loaded by the small miscellaneous texture table as mentioned before if the stage uses the same background for every single act of that stage (like Emerald Coast for example). Sometimes, like Windy Valley in the final Dreamcast build, the game actually contains the miscellaneous texture table for that particular stage in the stage file itself, utilized directly by a stage specific subroutine in the stage file that's called from 1ST_READ when the stage is loaded (this usually occurs when every act of a certain stage contains a unique background, such as the case for Windy Valley). Note that in the case of Windy Valley in the final build, even the textures for the objects are loaded this way! What a mess. So in short, the case for loading textures for each stage seems to be a stage by stage sort of thing and so there really isn't a common way the game loads it's textures for anything. That brings us to Windy Valley in the AutoDemo. 1ST_READ in this build is very particular on references to files that still exist in this build. For instance, the game is more than happy to contain an accurate pointer to the landtable (the level mesh) of Windy Valley, but because there's no texture file for the stage, the game completely neglects to acknowledge that one ever existed in any of it's tables (usually replaced by a null pointer, but not all the time). However, that's just 1ST_READ. The actual stage file for Windy Valley itself acknowledges the names of the textures contained within the texture files for the stage (sans the texture file name itself). My idea for restoring the textures for the stage/objects is pretty simple. I want to create a copy of all the relevant tables I can find in 1st_read and edit them to include new entries for Windy Valley. One small table for the "misc" Windy Valley stuff (OBJ_WINDY, the badniks, animals, etc), a new version of the 8C190DC0 table to include the new misc Windy Valley table, and new version of the table at 8C191158 to include an entry for Windy Valley (if I don't understand what the three other bytes mean I can always just follow what I see in the NTSC-J version of this table for ideas). I found some gaps in 1st_read where there's no data that I can use to stick some new data in without expanding the file. Once I have all the copies with my changes in them, I just replace all the old pointers to those tables with new pointers that point to my copies. For the backgrounds, I still have to figure this out since it's being loaded directly by a subroutine in the stage file, so I need to find out if 1st_read is still looking for this subroutine or if I'll have to hack it in somehow myself. Unfortunately I don't know where to begin with getting the textures themselves. There were efforts in the past to restore the textures by ID to the actual landtable before eventually switching gears to support Dude's import with some of the static objects baked into the level mesh. What I need is a literal recreation of WINDY01.PRS, WINDY03.PRS, OBJ_WINDY.PRS, WINDY_BACK.PRS, and WINDY_BACK3.PRS as it was intended for the original landtable/objects. Here are the texture lists I was able to locate (note, I'm not worrying about WINDY02/WINDY_BACK2 right now as there's too much missing to make putting it back in an easy task). WINDY00.PRS: WINDY02.PRS: OBJ_WINDY.PRS: WINDY_BACK.PRS (???): If anyone can help me out with this, I'd appreciate it. I can probably recreate the background PRS files myself, but definitely not the stage/objects. As far as the backgrounds are concerned, I'll have to look into it more. I'd imagine setting up the deathzones and path data for the stage are more or less in the same boat as it's the only way those things could load if they still exist, at this point at least. Also as a side note. I figured out what was wrong with that Rhinotank badnik having bad textures. Someone forgot to include the file for it's textures in this build, but the game still references the file itself. I took the PRS file from the NTSC-J Final (E_SAI.PRS), decompressed the PVM, decompressed the PVRs, renamed all the pvr files (since they had similar names), and repackaged the PVM file with the newly named pvr textures in the order as referenced by 1st_read. Compressed everything with PuyoTools, rebuild the GDI with GDIBuilder and... /> This at least proves that as long as the game references the file, you can repack the game with any extra file without having to worry much about anything else. Of course in the case for Windy Valley, I'll be adding new references to the tables of pointers myself so it shouldn't be an issue either.
God damn man, good luck to you. this sounds like a mountain to climb but its gonna be a hell of a payoff.
Regarding getting the textures... I read over the explanation twice and I'm not completely clear as to what you're asking. The unknown values, are they an obstacle to getting things to work or can you just use the most common values seen for those at the moment? Perhaps they're display related parameters? Or is your biggest obstacle just knowing which textures to pack into each ID? If so, didn't Dude need to ultimately solve that manually too? If that's the case, then you just need some dummy textures which are images of the hex ID's of the texture it represents. Look at screenshots and fill in the missing numbers until you've found them all. That seems to be the only way to do it without the original data, or am I missing something? I can run GD-ROM images on hardware if it's useful for some reason.
Heh, it's all pretty complicated to explain unless you look at the disassembly itself. It's not pretty, and it's difficult to comprehend unless you go through the disassembly like I have. The only thing I'm unsure of are these two bytes when referring to the pointers of the stage texture files: Code (Text): seg001:8C191050 StageTex_Beach01:.data.b 0 ;act number ; DATA XREF: seg001:tbl_stagetexturefileso seg001:8C191051 .data.b 1 ; field number seg001:8C191052 .data.b 1 ;don't understand this byte seg001:8C191053 .data.b 0 ;don't understand this byte I'm pretty sure it wont be a major problem since I can just look onto the final build to see what it's doing for Windy Valley. Since the AutoDemo doesn't have the texture files (either on the disc or referenced in 1st_read) I have to add the references back manually by creating copies of the tables that refer to the stage/object textures. Overall it's not that difficult to pull off. The only thing that might be a significant problem are loading the background textures, since those are loaded into the game by a subroutine within Windy Valley's stage file that is called only by an external function in 1st_read (in other words, not in a table like anything else). I don't know if the AutoDemo will still try to load the subroutine in the stage file or if it's been removed somehow. But I think I can figure it out in time. What I need are actual textures to work with though, since I don't really have anything to use and I'm not much of an artist. I was thinking of trying something like you said and what Catley and darkspines35 did earlier and just replicate the texture files with temp textures that contain an image of the ID value and just go from there. That would at least help me test to see if my methods are working as intended.
Do you need someone to convert all of the textures from Dude's mod to Dreamcast PVR format? Or do you need images with Hex codes on them? There are websites that can do this for you, example: http://dummyimage.com/64x64/000/fff.png&text=F2 Just trying to help in any way I can, without having to study the disassembly.
This is correct. I didn't port any code or behavior from the AutoDemo to the restoration. Objects without suitable replacements in the final version had their models ripped, and I duplicated and positioned them according to the SET file using a script. If they needed collision, I modeled that myself and also baked it into the world geometry. The object models were then baked into the final level geometry. Anything that required animation or custom code didn't survive. Much like the Spring Rock you mentioned. I'm actually surprised at how accurate my results were, looking at the things like the low rock-walls that hug the edges of the stage and the little signs that flap in the wind (although mine don't flap). Everything seems to be aligned and placed roughly the same. The video you saw was running at half speed. Everything was slowed down. That's why the spring animation looked so much calmer. Good work btw. Hopefully these videos will show people how big of a restoration actually had to be done to get things playable, let alone the 'completed level' state that it finally ended up in. I really wish I'd had these videos when I was working on it, although I probably still wouldn't have been able to get any of the object code ported.
Nice to see that stuff is still being found in this thing after 3 years. I've been lurking this topic since the day it was made but hadn't really gotten the chance to post until now. I know it's already been mentioned here once already, but I wrote an article on TCRF the other week with most of the stuff that can be found including a lot of the things that were discovered in this thread. There's still a lot of info missing from it but as far as I know it's mostly stuff to do with objects, such as what's going here now with Windy Valley along with other stages like Twinkle Park and Sand Hill. Dunno if this has been talked about yet, but is this used anywhere? It's listed as TAKO W, at least in SA Tools. Don't know all that much about going deeper myself. But regardless, looking forward to seeing what else can be dug up here. EDIT: Not really worth making a new post but here's the RAM addresses for the FPS if anyone wants them: 8C75D0A8 / 8C75D0B0. Kinda curious to see how Windy Valley would run at 60 FPS, seeing as how it already seems to slow down considerably with all those objects.
