Discussion in 'General Sonic Discussion' started by Orengefox, May 21, 2013.
Did any of those edits require you to make the stage.bin larger than it originally was?
I don't remember if I edited any stages to be bigger in filesize. Infact...I can't remember what all I've messed with to be honest...I just know I've been able to pretty successfully rebuild the game without any issues. I can always try it out later today and see if anything breaks with a larger stage file or not.
Edit: To do that though...do the current tools allow us to edit a binary and it not break that way? I just realized that may be a problem...
Well, these test stages sure are elaborate and highly advertised for what they are. The media coverage of this level was everywhere before its release. Even Yuji Naka highlighted this to showcase the game's action stages for that August 1998 unveiling. Nah, I think this design was intentional from the start until eventually someone from Sonic Team said "eh, maybe not."
I'll echo my statements from that first video to here: This early draft of Act 3 looks erratic, at least to my eyes. I know this is an approximation of what WV beta looked like using actual code and geometry ripped from the Auto-Demo, plus placeholder textures, but to me it feels foreign compared to the rest of the Sonic stages in SA1 (and maybe I was thrown off by the fact most of the level surfaces consisted of probably one single grass texture).
I don't know if I can articulate this well, but I feel as though the level structure is awkward to maneuver through. Some parts later on that level are narrow and look hard to run through confidently on the first few tries. I felt the final Act 3 nailed it with simple, yet thrilling railways that guided you to the next part of the level structure (which supposedly consist of falling ground platforms that were thrown away from the tornado). This early draft has you making a lot of stops, turns and unnecessary jumps, which totally slows down the action. I recognize it's suppose to be more non-linear and open field, but -- and I dare say this -- it's too complicated. Even with the placement of the trail of rings that are suppose to guide you to the next area, the very first impression I had seeing this, especially this part, was "I almost can't even tell where you would have needed to run off to." The lack of an auto-camera to guide you certainly doesn't help either (and don't get me wrong, I know the camera data wasn't available for this level to demonstrate). Now, this draft of Act 3 is fascinating but I appreciate the final design for Windy Valley now that I have a representative approximation of former to compare to. Am I wrong for thinking this?
And this is just another nitpick detail, but I feel as though GGZ Act 1's music is barely compatible with the tempo of this stage compared to the bliss pace of the final. Considering Windy Valley's music wasn't in the Auto-Demo (along with many other tracks, granted), I'm led to believe that this level had a messy development and it shows.
(Edit: I'm horrible at grammar. A revise was devised.)
Last year I modified the test level STG00.bin and the Mystic Ruin Chao Garden and compressed it back to PRS and was able to rebuild the GDI without issue. But it's been a while a go and I can't remember what I used to do it. But I never tested it to see if the game would work after replacing a file with a larger one.
I mentioned the pointer issue last year, and it's definitely one of the things that needs to be done. You can probably temporarily avoid having to worry about objects for the time being by replacing the loading subroutine pointers in the object list struct with the address of a ring. That way you might prevent the game from loading subroutines which contain jumps or calls to functions that exist outside of the file (1ST_READ). Of course all the objects will be rings, but it's a start. The other problem you'll have also deals with pointers. I think the stage file has some routines that aren't for any objects but for the level itself. The subroutines need to be changed for the same reasons as before. I was thinking of maybe NOPing everything except for returns, but I never tried doing that. Changing the pointers so that they point to the right places is easy with a hex editor - since you wouldn't be altering the file size you shouldn't have any problems rebuilding a GDI with the changes. But other than that, that should be the only things you need to change in the file itself. But of course you'd also need the texture files as well, but I don't know if the game will care if they exist or not (since the AutoDemo can load stages with references to textures but with no texture file without issue).
Of course there are also other possible problems as well, like the object SET limitations that might hinder the first act. And without a decent emulator with a debugger it'd be kinda difficult to trace the problems.
EDIT: Did we ever figure out if the tornado section of Windy Valley's land table exists in STG02.bin? We know that the pointer to it in 1ST_READ was zero'd out, but it's weird to think that the individual objects that make up the act exist but with no means to accurately connect them?
I played through the two stages a bunch more times and I think I agree with Dude and GeneHF - these levels are quite frankly too big and too chunky for Sonic Adventure. Not necessarily in size but in terms of how the game plays out. The openess, while that makes them grand, also makes them feel alien.
Theory time: I have a theory though about the version of Windy Valley in the AutoDemo; it's not even the most complete version of the beta stage, we've seen it more polished. I think it had been scrapped prior to the release of the AutoDemo but the replacement was not yet ready.
Looking back at the footage (mostly stuff I clipped from Sonic CulT years ago) I see windmills, rotating wind propellers, floating platforms, all of which missing. Some of them are objects that were removed from the game or probably have IDs that call upon other things now. However, IDs for the rhino tanks and the floating pink snake things are correct and in the right places compared to the footage we've seen. I wouldn't imagine that most of the objects in Windy Valley had their IDs changed.
I think the version in the AutoDemo is partially stripped out, after all, it used older level information instead of the current version. My guess is that it was waiting to be replaced with the newer version of the stage (the one from the full release) which was probably still being created at the time. Perhaps that, along with missing areas (isn't there one from from Mystic Ruins?), were still being polished or updated.
Definitely not. The final version has much more polish, and much better flow, although it does feel a little content-bare but considering the timeframe it was built in, they did a great job. It would have been nicer if they had been able to adapt the beta layout instead of starting over and only keeping the most general design, but that probably wasn't a realistic option given the time constraints they were under.
Yep, now you're starting to get it. Simple edits are easily portable to the dreamcast. A completely new level that is bigger in filesize than the original? That might be problematic. Directly porting the stage bins is futile due to complexity, but porting a re-make wouldn't be so bad - if we can find out if 1st_read.bin is OK with simply extending the size of the binary. If not, there's more research to be done. Basically, once we can port Mushroom Zone, we can port WV Beta.
Your ideas there might just work. It's still a fair amount of work for anyone to tackle though.
As for the Act 2 data, it turns out they're handled similar to objects. I don't know a lot about programming so this might not be right, but I know that all the pieces of the level are in what I think is a routine. It seems to usually follow a structure of a pointer to a model, then a pointer to some code related to the model. There's also some collision meshes in there for certain objects. The data starts at 0x15A278 in STG02.bin (May not be entirely right, it's just what I used to get all the models I could find), so someone more knowledgable than I could probably figure out what all is going on.
I have a feeling this is pretty accurate. From my research on the topic, I've come to realize this iteration of Windy Valley was gone in media releases in late October which means this was likely the last version of Sonic Adventure to have the files in it at all.
The majority of the objects between the beta and final are entirely different. evilhamwizard actually corrected the IDs of the enemies and some of the objects to give it a better feel when ported over. This was because all of the objects except for the first few, the common objects, are not the same in terms of IDs. In comparison, Beta Windy Valley had a total of 114 objects in its Object List where the final only has 79.
Wow, that's a lot of object types. I didn't realize the stage had gone through so many changes.
Perhaps it was the first stage created, and the very last to be finished?
I like this, it is exciting to think about. It brought back my passion for theorizing about game development history.
Not currently, but it would be possible to take the old buildPE code, remove the stuff specifically for Windows, and have it just tack data on the end.
Apologies if this has already been answered...but why not figure out why it's not loading in the AutoDemo?
We know exactly why it isn't loading: all of the pointers to common code and data from 1ST_READ.BIN are for an older version of the file than the AutoDemo has. It jumps to invalid code and crashes.
Thinking about it further, I don't think they would have a file size limit. The PRS decompressor would just decompress the data to a fixed address in memory until it reaches the end of the file. The only limits would be where other data is loaded.
Got the textures working. I should be able to finish the rest of this in a reasonable amount of time. Although, now that I've played myself, the level isn't as big as it looks. I think the reason it looks so big in the original videos is because they were playing the game at half speed, and because of the camera angles chosen. I definitely think development time was one of the main reasons they cut this down.
Yeah, it doesn't look nearly as big now, but it definitely shows off how much of a mess that level layout is. It's very much for the best they re-designed the level for the final version.
My soul just ejaculated.
I'm sitting here, watching this, thinking... "It doesn't get much better than this."
[EDIT: I released a (now outdated) video this morning about the level, looks like the follow-up with the full level is sooner than I first anticipated.]
This whole level reminds me a lot of Bob-Omb Battlefield... I'm thinking this might have been the first thing they made after Sonic World, before they realized that a Sonic game needed a more fluid progression than Super Mario 64.
Given that Sonic Adventure uses a very old SEGA 3D model format, and the similarity with the textures, I would not be surprised if this was made in that Sonic World era. It wouldn't be too much of a stretch to say that, considering magazine interviews with Yuji Naka which stated that the game was conceptualized immediately after the release of NiGHTS. Windy Valley (Beta) definitely looks like it would've been channeling that Sonic World vibe.
I have a feeling that when Yuji Naka described the large 3D world he made for Sonic in the 1998 October issue of SEGA Saturn Magazine...
...that he was talking about the second half of this Windy Valley stage.
The more I play it, the more I'm convinced the second half is a "test level" - either that, or the slope and wall behavior for Sonic was very different during that stage of development.
All this does is strengthen my theory that the Windy Valley stage was the very first area created, and the very last one replaced.
[Edit: That one typo that keeps you awake at night.]
I just want to remind everyone that a great deal of your design instincts about the level will be off because you don't have a completed camera file. The camera layout is absolutely a make-or-break part of a level design, as it directs the player where to go and allows them to flow through the level.
I remember there were some elements in an actual test level that just flat out didn't work with the final physics, but would have worked with more Mega Drive-ish physics applied, so that might be it.
Regarding the restored stage, I think everything is a bit too well constructed for a test level. More like a "work in progress" if anything, in my oppinion.
You're right, the camera data is important. It might seem almost arbitrary at a first consideration (knowing how finicky the camera in Sonic Adventure can be), but it is entirely responsible for guiding the player through the stage when there aren't cleverly placed enemies, guide textures or rings lying around.
Is there any chance of us ever getting a hold of the camera data? I was under the impression that the version of the stage from the AutoDemo was either partially stripped out or incomplete. Unless the camera data was never finished to begin with. I believe this to be the case, because-- Looking at this video, it is clear the level did have some very effective camera data, so I was wrong to believe this.
Watching this footage, it appears as though the stages actually could have worked well, the parts shown here certainly flowed.
To get decent camera data, we're going to need a prototype from before the level was officially cut, and I don't think that is going to be possible.
[Edit: Getting that video to show up, the problem is that I use https instead of http.]
The first part of the stage comes with camera data. It needs work but the volumes should all be usable, at the very least. The other two parts do *not* come with camera data. But that does not mean decent camera data is impossible. It just means you'll need someone who understands the game's camera system and design philosophy to design new camera layouts. Luckily I know just the guy.
Separate names with a comma.