Ah, yeah that's TAKO W. I made a mistake in labeling some stuff years ago and I guess I thought this was the tornado. I looked into the tornado itself and I believe it's actually being loaded when the stage loads by a function call from 1st_read, not like a typical object in a set file. So that might explain why the object itself doesn't appear in a set file - it doesn't seem to appear in the object list at all even though the model/code for it seems to exist I saw that TCRF article and it looks really good. /> I posted some unused stuff from EVENT_ADX.AFS a few posts ago that might have some good stuff for the article. Hopefully this and the other SA1 articles get expanded soon, especially the region differences between the International and original NTSC-J releases. Hmm, the dummyimage site looks great. I'll see if I can put together some temp textures first to see if my idea will work. If it works I'll probably ask darkspines35 if I could use his textures since he did a good job identifying the ones used for the stages. I'm not sure about objects though, but I'll figure something out. Heh yep. I'm glad someone took a crack at it since I would've never been able to restore everything to the extent that you did. I never thought that anything that I was doing was going to work but luckily I managed to get to a point where I might be able to restore everything. But personally I would still prefer a complete AutoDemo level mod for SADX PC over my own attempts, hehe. Some good news btw. Just as I thought, the game does have "init" functions for individual stages and luckily has the pointers for them in a table right near the init coordinate table begins for each character. The table begins at 8C16EC6C in the AutoDemo, and fortunately the pointer for Windy Valley still exists! Oddly enough, the pointer itself (which points to C907C60) isn't a bad pointer and actually points to the correct function. This means that the game will try to load the code to init the stage as is, and the only modifications that I need to do for the init function itself is to restore the code with the correct pointers. The great news is that judging by some of the function calls, it seems that this subroutine is responsible for calling some functions that do stuff with the tornado, even going as far as to load some textures for it I think. I think the deathzones and path data are init by this function as well, so I might be able to get that working as well. It's a pretty big subroutine to restore, but hopefully I can restore it properly.
struct LevelPVMList { __int16 Level; __int16 NumTextures; PVMEntry *PVMList; }; A lot of the stuff you've been documenting in the previous posts for how textures are loaded is stuff the SADXPC disasm already has labeled and figured out. Granted, a lot of it isn't written down anywhere, but you can always look through the disassembly yourself, or ask on irc.badnk.zone #x-hax if you don't understand something. Sorry it took so long to respond, I missed that the topic had been bumped.
Wow, this is amazing work. I'd thought restoring Windy Valley to a playable state in the AutoDemo was something we could only dream of, but it seems like you're making great progress with your restoration! Fascinating to see all the little moving objects providing background details - I think it's safe to say Sonic Team were pretty ambitious when constructing this version of the level. Will be very interesting to see if you can get it to accept textures for the stages. I know the original textures aren't available, so Dude's SADX mod seems a good starting point for resources in that regard. If I recally correctly, it used a combination of matching textures found in the final game (I think one of the proto-Windy Valley pathway textures turned out to be reused for the Chao races in the final game, if memory serves?), and original/modified textures where no match could be found. Most were incredibly accurate - at the time, I only noticed a couple of discrepancies through comparing vids of the mod with the existing prototype screenshots & footage of the level. While it wouldn't be 100% exact to how the stage would have looked, it would definitely give a pretty good indication and probably be as close to the real thing as we'll ever get - short of somehow finding an even earlier prototype, of course...! = P Out of interest, is there any evidence of lighting/camera set-ups defined for the stage anywhere in the AutoDemo's files? Love the lighting in the DC version of Sonic Adventure - a lot more polished and atmospheric than the later ports - but I'm very aware many stages in the AutoDemo have unfinished or missing lighting, so I'm not really holding out much hope in that regard. Congratulations on your restoration so far - your hard work is getting some amazing results. Needless to say, will be keeping my eye on this topic with great interest. = )
I've heard that Adventure was originally meant to be a RPG. Is that true? Has any remnant of such a thing been found? EDIT: wrong topic to ask this, it seems. =P
Going to do some cross-posting here seeing as it may be relevant to this topic. The following quotes were originally posted in this topic [HERE].
Hmm, I'm not sure about the lighting. I think the lighting in SA1 uses an automatic vertex shading (is that the technical term for it?) that's activated with a simple flag in memory. I recall SADX Preview let you flip it on and off with a button press but I'm not sure how to do it with SA1. I think every stage in the final SA1 used vertex shading, but only some stages have it enabled for the AutoDemo (like Speed Highway, if I recall). I guess it's only a matter of figuring out how it flips the setting on per stage. The camera set-ups are still here, but they don't work as is with the game's current camera system. So they'll need to be modified to make whatever the files are doing more compatible with that the game expects. On a side note, I've done A TON of restoration work on Windy Valley and have loads of crap to share. I'll get into it more later when I have time, but at this point I have restored every single object (in the object list) with functionality. I even restored a few objects that go unused in this version of Windy Valley (like TakoW and EE103). I even possibly discovered some unused objects that go completely unreferenced within the stage file itself but the code and object model still exist. Nothing crashes the game except for the trampoline object, which still crashes with Sonic for some reason (I'm gonna need help with this I think, I have no idea what's wrong with it). I also FINALLY figured out how the stage's leafy path stuff worked and managed to load it up and display properly in game. However, unfortunately either because of a bad parameter pass to a subroutine or the data itself, the path itself doesn't function correctly when you walk on it (it just propels you in the opposite direction at high velocity with no way to stop). No idea if I can fix it. I also restored the necessary functions for displaying and animating all the backgrounds for each act, now I just need to create, add, and load up the texture files for them to get them to work as right now it just outputs garbage. I found the array in 1st_read that had the pointers for each stage's deathzone structs, but suspiciously the one for Windy Valley is null'd out. I can't seem to figure out if this data still exists in the stage file so that I can either create a new pointer or write up a table from scratch and make a new pointer that points to it. Does anyone know if this data still exists? It should still be in the stage file, at leas the OBJECT struct for the death zone mesh itself. Oddly enough, the game actually nulls out alot of entries in the stage deathzone array/table, even for things that can be played in the AutoDemo (like Emerald Coast). So that explains why you don't die if you fall out of the stage in some zones. Very weird. I wanted to post something here because I found something very bizarre that I need confirmation on (especially from the people who had a hand in restoring Act 2). As was stated before, the game lacks a landtable for Act 2. However, the stage file still contains the individual object/model pieces that would've made up the act's landtable, and the reconstruction is what you see in Dude's mod. A lot of information about Act 2 is unfortunately missing entirely or simply unreferenced, or a combination of both - so this makes restoring the act in the AutoDemo near impossible without lots modifications. However, I found something strange that I need some input on. The stage file has a few completely unreferenced functions, one of which is at C90AC64. The function itself contains a lot of references to texture list heads and a reference to a table which contains a bunch of object/texture head pointers that are only referenced here. Each model referenced in the table includes a fixed X/Y/Z value attributed to it that places each model in a specific spot. I can only load one model at a time, but I can tell that these models look like platforms and paths. Here's what the table looks like: Code (Text): ROM:0CA5A278 off_CA5A278: .data.l unk_CAA29D0 ; DATA XREF: sub_C90A860+80o ROM:0CA5A278 ; sub_C90A860:off_C90A98Co ... ROM:0CA5A278 ; wtf ROM:0CA5A27C .data.l stru_CAA23A4 ROM:0CA5A280 .data.l 0 ROM:0CA5A284 .data.l unk_CAA4E64 ROM:0CA5A288 .data.l off_CAA2A1C ROM:0CA5A28C .data.l stru_CAADBE4 ROM:0CA5A290 .data.l unk_CAA57A0 ROM:0CA5A294 .data.l stru_CAA4EB0 ROM:0CA5A298 .data.l stru_CAA234C ROM:0CA5A29C .data.l stru_CAA6198 ROM:0CA5A2A0 .data.l stru_CAA5804 ROM:0CA5A2A4 .data.l 0 ROM:0CA5A2A8 .data.l unk_CAA70FC ROM:0CA5A2AC .data.l off_CAA6208 ROM:0CA5A2B0 .data.l 0 ROM:0CA5A2B4 .data.l unk_CAA88B8 ROM:0CA5A2B8 .data.l off_CAA7178 ROM:0CA5A2BC .data.l 0 ROM:0CA5A2C0 .data.l unk_CAA91F4 ROM:0CA5A2C4 .data.l stru_CAA891C ROM:0CA5A2C8 .data.l 0 ROM:0CA5A2CC .data.l unk_CAA9A30 ROM:0CA5A2D0 .data.l stru_CAA924C ROM:0CA5A2D4 .data.l 0 ROM:0CA5A2D8 .data.l unk_CAA9FF0 ROM:0CA5A2DC .data.l off_CAA9A88 ROM:0CA5A2E0 .data.l 0 ROM:0CA5A2E4 .data.l unk_CAAA740 ROM:0CA5A2E8 .data.l stru_CAAA054 ROM:0CA5A2EC .data.l 0 ROM:0CA5A2F0 .data.l unk_CAAAF14 ROM:0CA5A2F4 .data.l off_CAAA7A4 ROM:0CA5A2F8 .data.l 0 ROM:0CA5A2FC .data.l unk_CAAB66C ROM:0CA5A300 .data.l stru_CAAAF78 ROM:0CA5A304 .data.l 0 ROM:0CA5A308 .data.l unk_CAAC79C ROM:0CA5A30C .data.l off_CAAB6DC ROM:0CA5A310 .data.l 0 ROM:0CA5A314 .data.l unk_CAAD2E4 ROM:0CA5A318 .data.l off_CAAC7F4 ROM:0CA5A31C .data.l 0 Here are what some of the object models look like, some of these I know were definitely used in Dude's restoration of Act 2: CAA29D0 CAA4E64: CAADBE4 CAA6198 CAA70FC At first I thought this was the debris for Act 2, but these are actually part of what I assumed was the landtable for the stage itself. Does anyone know why it's like this? It almost seemed to me that they didn't want to use a landtable for Act 2 and instead used a function to load all the individual models together instead. The only problem is that whatever was supposed to load everything from the table above is unreferenced and isn't executed anywhere. I have no idea how it's meant to be called (my guess something in 1st_read maybe?). I want to follow up with a proper post with tons of stuff soon. I just need to import the function/branches that load of the stage specific objects that I mentioned before. After that, I just need to tie to loose ends to see if theres anything else that needs to be looked at in the stage file itself before I make the proper modifications needed for the textures to load properly. So stay tuned. EDIT: Oh, I forgot to mention. I know how Act 1's tornado object is supposed to come into the stage. In the final, it's an actual object if I remember correctly. In the prototype, it actually slithers from a corner of the stage as you approach the end. That's why if you manage to get to that part of the stage, there's a huge chunk of the wall missing on the left side - that's because that's where the tornado's supposed to pop out of. Ironically, you can see this in action in a super old Sonic CulT video, to which I have no idea where this particular footage is sourced from (gg ez CulT): It's at 1:04 in the video. I completely forgot this video even existed.
Double posting because I finally finished importing all the code for this stage file. And I got this to load /> : As I said before, the tornado itself isn't really a stage object that's part of the object table. It was originally meant to be called as part of another function which initializes other stage functions based on certain conditions, this one being that if I'm close to the edge at the end of Act 1. The tornado loads from the left near a hole in the wall and moves into focus while waving back and forth waiting to suck up the player from the air vent ahead. The Tornado will gradually rip apart pieces of the level geometry itself and move closer to the player when the you get sucked up. Unfortunately it crashes the game when you go inside, possibly because of the level change. Act 2 doesn't work anymore, possibly because the subroutine I restored for the stage objects are trying to look at things that either aren't loaded before the code is called or it's interacting with things that no longer exist. Bummer. The strange thing about the object is that apparently the textures for the dust animation apparently still exist somewhere - I did NOT add that in, so that's actually an original texture. I guess the stage file itself still had them in somewhere? Act 3 works fine though, there aren't any additions made to the stage itself by restoring the code for the stage objects. Now I can finally begin restoring the rest of the textures, possibly restore the music, and look into fixing the camera file. Then I can finally move away from this mess. Ha.
This just keeps getting better and better. I never thought we'd manage to find the most interesting part of the beta Windy Valley like this.
Too cool. I hope the reason they redid the level was due to performance issues -- this version is SO much more interesting.
I wonder if the method you used to get the level working in the AutoDemo could also be used to port it to the final?
I thought about it, it's technically possible but there's only one thing that's kinda in the way. I could locate the equivalent pointers in the final and replace everything with those instead, and then modify the pointers in 1st_read for Windy Valley to point to the locations in the AutoDemo's stage file (like the stage object function, the texhead for the stages, deathzone, path data, object list head, etc). The only problem that I think might happen is that the function calls in the stage file for things in 1st_read have a higher chance of working incorrectly or crashing because I noticed that the function calls themselves were passing parameters using different registers between the two versions. Technically you could modify the byte code to change the instructions to use the correct registers but it's kinda a crapshoot. You'd also have a problem with how the function that's being called in 1st_read returns values. Overall I think it could be done, but with the AutoDemo being the next build from whatever build Windy Valley and the other nonworking stages with bad pointers come from (possibly the TGS demo build), it's definitely easier to work with the AutoDemo instead. I'm sure that you could at least get the landtable to show up by 'nop/ret' all the code in the beginning like I did, repackage the PRS, and rebuild the GDI. Hell you could make custom stages very easily with this as a base. You'd just need to compile your custom landtables with a 0C900000 base address little endian in Visual Studio, and go into the landtable pointer array in 1st_read and change a pointer so that it points to the new landtable in the stage file. What I'd like to do for the AutoDemo is hard patch some fixes in 1st_read to let you press start to skip the movies and at the title screen and have it forward to the developer level select. That way you could have access to everything without having to use Cheat Engine. I'll have to look into it once I have Windy Valley working the way I like. Anyway, before I get to work on the textures I wanted to show off tons of other stuff I found while restoring the pointers. The first thing I wanted to show off were some unreferenced objects. These are objects which the code and object model for them still exist but the pointer to them doesn't exist in the object list for the stage (meaning they can't be loaded without replacing a pointer in the list). These objects aren't that spectacular so I didn't bother loading them up in game. Instead I'll just show off what they are in SAMDL. Since these objects don't appear in the object list, there aren't any names associated with them. When I mention the objects, I'll mention the main subroutine that loads the model as the name, which in this case will be that address. The first object is "sub_C9022C0", which its model is located at CA3548C: The second object is "sub_C9022DA", which its model is located at CA3630C: The third and possibly last object is "sub_C9022F4", which its model is located at CA36AA4: Yeah, I don't know what any of these are either. No pointer exists that point to these, and the models themselves are only referenced by these subroutines. The objects themselves are static, and don't do anything at all. All three objects have their own subroutine, but each subroutine is exactly the same: Code (Text): ROM:0C9022F4 Load_UnusedObject3: ROM:0C9022F4 mov.l @(h'20,r4), r5 ; Move Structure Long Data ROM:0C9022F6 mov.b @r5, r0 ; Move Byte Data ROM:0C9022F8 cmp/eq #0, r0 ; Compare: Equal ROM:0C9022FA bt GetObjStructPtr ; Branch if True ROM:0C9022FC cmp/eq #1, r0 ; Compare: Equal, did we get the pointer for the object struct? ROM:0C9022FE bt DisplayObjStruct ; Branch if True ROM:0C902300 bra DisplayObjStruct ; Branch ROM:0C902302 nop ; No Operation ROM:0C902304 ; --------------------------------------------------------------------------- ROM:0C902304 ROM:0C902304 GetObjStructPtr: ; CODE XREF: Load_UnusedObject3+6j ROM:0C902304 mov.l #Obj_UnusedObject3, r3 ; Move Immediate Long Data (CA36AA4) ROM:0C902306 mov.l r3, @(8,r5) ; Move Structure Long Data ROM:0C902308 ROM:0C902308 DisplayObjStruct: ; CODE XREF: Load_UnusedObject3+Aj ROM:0C902308 ; sub_C9022F4+Cj ROM:0C902308 mov.l #h'8C04A4A0, r3 ; Move Immediate Long Data, (8C04C560 is the correct ptr) ROM:0C90230A jmp @r3 ; Jump ROM:0C90230C nop ; No Operation ROM:0C90230C ; End of function Load_UnusedObject3 These subroutines are sandwiched between the main subroutines for WcWind and Baneiwa. Other than that, they look very simplistic and are probably roughs for some static scenery. Next, let me show off some unused objects that ARE referenced by the stage's object list. These can be loaded in game by changing the ID of an already existing object in a SET file, or by adding a new entry in the SET file with the ID of the object you want to load. There are 17 unused objects in the object list, some more interesting than others: (Note: Some of the gifs are pretty big so I'm linking to them instead of displaying them directly here) 16 - bleaf: http://i.imgur.com/p05feLJ.gifv Very interesting but pointless object, probably for decoration. It's difficult to see in the gif, but the object spews out leaves which gracefully fall down in a zig zag when you walk near it. You can control the angle in which they spawn based on the direction you're facing when you walk toward the object. 1b - PROPE3: A simple propeller with no collision. No idea where this could've been used. 24 - GRASS3: Just some grass, definitely used in Act 1 at some point. 25 - GRASS4: More grass, possibly going to be used for Act 1 at some point as well. 38 - Yaji01: A sign post. Possibly used for Act 1 at some point. 3d - Pot01: Very similar to the used objects in Act 3 that are used before the leafy paths. 3e - Pot02: Similar to the previous one but with a difference design. 49 - IDai7: A simple rock. Most of these Dai objects are used in Act 1. 53 - TakoW: http://i.imgur.com/aGWpmG8.gifv Very strange net like object. It has no collision, but it certainly looks like it would've been more interactive. 55 - Dome2: http://i.imgur.com/ivG2mkJ.gifv Similar to Dome1 but with two propellers instead of one. 56 - Dome3: http://i.imgur.com/fFcK5iz.mp4 Similar to Dome2 but with three propellers instead of two. 57 - Prop1: This looks similar to another object used in the final's Act 3. So this might've been used in Act 3 at some point as well. 59 - PropeB: This looks similar to PropeC, which is used in Act 3. But this one has two propellers instead of one. 5b - IwaB: Another rock. 6e - Wele: http://i.imgur.com/kVcoW1h.gifv Here's a cool object. It looks like some kind of elevator. It's not big enough for any other characters besides Sonic/Tails/Knuckles/Amy. The object will move all the way down and disappear after a certain amount of distance, and then respawn when you leave the area and come back to where it initially loaded. Who knows where this would've been used. 71 - ELeon: This guy! He appears in Tails' version of Act 3 in the prototype, and Act 3 in the final. Since there's no set file for Tails for Windy Valley, this goes unused. The object itself doesn't normally appear in any other working stage in the AutoDemo, so this is the first time we get to see him work in this build. There are only two differences as far as I can tell. Firstly, his tongue doesn't hurt the player. And second, he's invincible and cant be destroyed as far as I know. 72 - EE103: http://i.imgur.com/JCcnhls.gifv E-103! Used in the final but goes unused in the prototype because Gamma lacks a set file for this stage. One obvious difference here is the lack of the Delta symbol, so originally his title card just read E-103. When you defeat him, the camera doesn't fix itself on him when he explodes. You can beat him in 5 hits and the game will automatically clear the stage like it normally does, and end with a "Coming Soon!" screen and go back to the title screen. One annoyance with this object, which I can't remember if this happened in the final, you can't attack him as he hovers in the air. You can hit him when he jumps initially, but as soon as he starts gliding he won't come back down, possibly because this isn't the right arena to fight him in. While technically used, I'm also going to post some objects that appear in Act 2. Since I can't seem to get Act 2 working, and I might not ever be able to, I'll show you what loads in Act 2. 2a - T_Raft1: An extremely tiny platform. This has collision, and I think if given the right parameters can actually float up and down. But it's not very practical as it's so small (maybe it was meant to be scaled by the set file as well). 2b - T_Raft2: Another oddly shaped platform. When I had act 2 working initially with just the set file objects this was programmed to quickly float up and down. But it's a very strange shape for a platform so I'm not sure why they went with this initially. It's very difficult to stay one when it moves up and down. 6b - TSpring: (no picture): This might have a model to it, but if there is the data for it actually exists in 1st_read rather than the stage file itself. There are three pointers to data which I could not restore - 8C15CDCC, 8C15D218, 8C15D5A8. These pointers are accessed all at once, and should appear within 8C16E7D8->8C17A0FC in 1st_read. But I can't tell what kind of data this object is looking at with the three pointers. And who knows if it even still exists. These three pointers are unique to Windy Valley, and since this object no longer exists in the final version, there's no telling what these are actually meant to do. My guess is it's supposed to be data for a spring model, maybe even the common spring or some variant of it. As for the object's code itself, it does actually function and will interact with the player. All it does is launch the player in the air like a normal spring. Besides that, that's all there is to say about this object. 6c - Lauchin: http://i.imgur.com/Tyu8hYT.gifv This is probably similar to what TSpring was supposed to be. In this case, the model for this object still exists and is stored in the stage file. The logic is the same as the previous object, it's just a normal spring. However, this object is pretty interesting as the spring itself is very small and actually has a coil to it. When it launches you in the air, it actually detracts very slowly when you land on the ground. I wonder why they even bothered with so many spring objects. Using the common spring would've been easier, heh. Finally, objects aside, there is one observation I noticed that I forgot to mention. Sonic, Tails, and Gamma still have initial coordinate values when loading into the stage. Sonic still has his coordinates for all three acts, Tails has his for just Act 3, but the weird part is that Gamma still has his coordinates for all three acts for some weird reason. He spawns in the same spot as Sonic in all the acts. I wonder if this means that Gamma was meant to actually be able to go to Act 3 to fight E103 originally. It would kinda explain why he's in Act 3 in this stage, although this picture has a lot wrong with it so probably not:
With regards to patching fixes for the autodemo, would it not be possible to make it function like the demo title in the final? Pressing start takes you to the TGS character select and pressing X+Y takes you to the dev level select. With that it would for the most part function as if it was the TGS build with level select enabled. Also, the 'quick menu' Mainmemory found in the PC version that he used instead of the removed dev level select in the TGS mod does exist in the dreamcast final, so it potentially still exists here. Going to get back to looking into it soon.
There's a few stages in the Autodemo where the characters that play the stage have starting coordinates for Acts they don't usually go through. Amy and Gamma have Sonic's starting coordinates in every Act of Final Egg except the one Amy plays, as has Big and Sonic also having starting coordinates for Emerald Coast 1 and 3 respectively, though in Act 1 Big doesn't start in midair like Sonic does. I checked the final game just now and it happens there too, with Gamma even keeping Sonic's original starting point for Final Egg 1. On the matter of putting characters in places they don't normally go, there seems to be an invisible tunnel or something at the origin in Icecap 1-3 that isn't in the final game, so you won't immediately fall and die there if you try to enter as someone without a starting point. I have no idea what's going on with its collision though: Still love all the work you're doing on Windy Valley though, pretty amazing stuff. />
Getting there. />/>/>/> Thanks to darkspines35 and Catley I was able to get a jump start in restoring the textures for the stage. I originally wanted to try the method I stated before that involved making a copy of the stage texture array and modifying it so that it had entries for Windy Valley. For some very weird reason though, it won't work. It doesn't crash the game or anything, my efforts still allowed all the other stages to function, but the textures still wouldn't load up at all for Windy Valley for whatever reason. In the end, I sorta cheated and modified the landtable for both acts so that the landtable flag was set so that the entire level had both a texhead list and a texture name (0x08 in hex, after the first two words in the landtable struct itself), then added a pointer to the file name of the new texture file. I didn't expect for this to work, so I was amazed that it did. However, this isn't the correct method as it's very clear that the game was meant to load up the files necessary for the stage textures with the method I mentioned earlier. As you can see, textures are still missing here and there which can be random at times especially after reloading the act again. Because the texture file wasn't loaded using the original method it was supposed to, it doesn't release/clear the textures like it should when you reload the stage - causing glitches like the one in the shots (as well as replacing textures that were already loaded). The pointers to the texhead in the stage file only set the textures to the geometry, nothing loads a file at all. So this means that any work was originally done by 1st_read. Another problem with my current method is that there's no way to load the background/skybox textures (unless somehow I can sneak it in the table for object textures or something), so I have to see if my original plan will work or not. Luckily, for some very weird reason, 1st_read still has the misc texture/object texture file array for this stage. The only thing off about the array was that since the game lacked the files for the textures, the pointers to the filenames were null'd out. However, the pointers to the texheads were still there! So I just hacked in the strings for the missing file names and added a pointer where the null pointers were so everything loads correctly. Objects are loaded fine with no issue, although many objects still have temp textures as it was probably difficult to determine the right textures before. I'll still see if it's not possible to still do my original method. I'm still trying to debug it, but hopefully I make some progress. In other news, I finally figured out what the hell was going on with the lack of lighting/shading in some stages. As it turns out, the build of the game is missing tons of PL_/SL_ (Palette/Source respectively) files, which are used by the game's lighting engine (which is called LANTERN, a palette based engine). The LANTERN lighting engine is exclusive to the Dreamcast version, which is why no other version quite looks like it I think. The game stores two lantern data files for use in the engine for every act/segment. The file names are formed PL_/SL_*Letter*Segment Number*B.BIN, where "letter" is the representation of the stage number (not hex, for some reason). So for example, the lantern palette and source files for Windy Valley act three would be PL_ or SL_22B.BIN. Now obviously since the files no longer exist in this build, they had to be created. Luckily, the final's lantern files are fully comptatible with the AutoDemo. So what you're seeing is the final Windy Valley's lighting, which works pretty well. Adding the files were super easy. Since the game doesn't hard code all these files in one big array, the game automatically will try to find the lantern files by taking the current stage/segment number. If the file can't be found, which is very common in the Autodemo, the game will still let you play but without lighting. This is also handy for getting lighting/shading to levels in the AutoDemo that lack textures (like the Test Stages and Casinopolis, see below). Aside from restoring the lighting, I also took a look at the broken camera file for Act 1. As it was stated earlier, the camera file comes from a much older version of the game. What wasn't stated, however, was that the main reason why it was working the way it did was due to the order the camera types had changed over development. Camera types were introduced, but rather than be added at the end of the array/table or whatever, camera types were shifted around in the list instead of being removed outright. The Autodemo has just a few less systems than the final, but whatever Windy Valley's camera file was based on featured much less. Every version of the game actually sports a full fledged debugger specifically for camera stuff. As reference, it will tell you the name of the current camera type being used. Both the Autodemo and the final Japanese release feature a few different camera types. Take a look here: Autodemo: Code (Text): 00 - FOLLOW 01 - A_FOLLOW 02 - MAGONOTE 03 - A_MAGONOTE 04 - BUILDING 05 - POINT 06 - A_POINT 07 - LINE 08 - A_LINE 09 - ASHLAND 0a - A_ASHLAND 0b - KLAMATH 0c - A_KLAMATH 0d - ADVERTISE 0e - TORNADE 0f - TORNADE_V 10 - SNOWBOARD 11 - CHAOS 12 - CHAOS_W 13 - CHAOS_P 14 - CHAOS_STD 15 - CHAOS_STINIT 16 - TAIHO 17 - SURVEY 18 - CART 19 - BACK 1a - BACK2 1b - FOLLOW_G 1c - A_FOLLOW_G 1d - RuinWaka1 1e - LR 1f - KNUCKLES 20 - A_KNUCKLES 21 - FISHING 22 - A_FISHING 23 - TWO_HARES 24 - SONIC 25 - A_SONIC 26 - SONIC_P 27 - A_SONIC_P 28 - E103 29 - C_FOLLOW 2a - C_MAGONOTE 2b - C_POINT 2c - C_ASHLAND 2d - C_KLAMATH 2e - C_KNUCKLES 2f - C_SONIC 30 - C_SONIC_P 31 - FIXED 32 - A_FIXED 33 - C_FIXED 34 - NEWFOLLOW 35 - A_NEWFOLLOW 36 - C_NEWFOLLOW 37 - EGM3 38 - E101R 39 - EDITOR 3a - GURIGURI 3b - PATHCAM Final NTSC-J: Code (Text): 00 - FOLLOW 01 - A_FOLLOW 02 - C_FOLLOW 03 - COL_FOLLOW 04 - KNUCKLES 05 - A_KNUCKLES 06 - C_KNUCKLES 07 - COL_KNUCKLES 08 - KNUCKLES2 09 - A_KNUCKLES2 0a - C_KNUCKLES2 0b - COL_KNUCKLES2 0c - MAGONOTE 0d - A_MAGONOTE 0e - C_MAGONOTE 0f - COL_MAGONOTE 10 - SONIC 11 - A_SONIC 12 - C_SONIC 13 - COL_SONIC 14 - ASHLAND 15 - A_ASHLAND 16 - C_ASHLAND 17 - ASHLAND_I 18 - A_ASHLAND_I 19 - C_ASHLAND_I 1a - FISHING 1b - A_FISHING 1c - FIXED 1d - A_FIXED 1e - C_FIXED 1f - KLAMATH 20 - A_KLAMATH 21 - C_KLAMATH 22 - LINE 23 - A_LINE 24 - NEWFOLLOW 25 - A_NEWFOLLOW 26 - C_NEWFOLLOW 27 - POINT 28 - A_POINT 29 - C_POINT 2a - SONIC_P 2b - A_SONIC_P 2c - C_SONIC_P 2d - ADVERTISE 2e - BACK 2f - BACK2 30 - BUILDING 31 - CART 32 - CHAOS 33 - CHAOS_P 34 - CHAOS_STINIT 35 - CHAOS_STD 36 - CHAOS_W 37 - E101R 38 - E103 39 - EGM3 3a - FOLLOW_G 3b - A_FOLLOW_G 3c - LR 3d - COLLI 3e - RuinWaka1 3f - SNOWBOARD 40 - SURVEY 41 - TAIHO 42 - TORNADE 43 - TWO_HARES 44 - LEAVE 45 - EDITOR 46 - GURIGURI 47 - PATHCAM Luckily, Windy Valley's old camera file only makes use of 7 different camera types. From my notes, this is what I figured (some of these are definitely wrong and need more researched): Code (Text): 00 - FOLLOW (no need to replace) 03 - A_MAGONOTE (guessing, might not need to be replaced) 05 - POINT (needs to be replaced) 08 - MAGONOTE (replace with 02) 0d - A_SONIC (replace with 25) 0f - COL_SONIC (doesnt exist in autodemo, could be A_SONIC_P which is 27) 11 - C_FOLLOW (guessing, trying to replace with 29 These were found by using a copy of a spare camera file that remained completely unchanged besides the camera types specified. I forget which file it was, but I was also able to confirm this along with it: 0a - (this should be 0e in ntsc-j final - "C_MAGONOTE") 08 - (this should be 0c in ntsc-j final - "MAGONOTE") 0c - (this should be 10 in ntsc-j final - "SONIC") 0f - (this should be 13 in ntsc-j final - "COL_SONIC") In short, the camera is working a bit better than it did before but still far from ideal. If I get to recording another video, I'll show off what I mean as it's difficult to describe. Finally, some misc things: (this should be easy to repair once I'm done with Windy Valley) This is Twinkle Park Act 1. For some reason, there's this big thing in the center of the bumper car ring that has no collision. This is NOT an object, and doesn't exist in the final for sure. For some reason as well, the objects in this stage's set file don't match at all with the layout of the stage (it looks as though nothing appears). Very strange. EDIT: I got the original method that I wanted to use for loading textures working, but the results are still the same as above. It seems that the object textures are taking up too much memory (the uncompressed pvm is close to 2mb), as nulling out the pointer to the object texture file restores all the stage textures.. The 5th byte in the landtable for both acts (which is the landtable 'flag') is set to 02000000. This is wrong for some reason, as the final's Windy Valley uses 0C000000, which when used in the Autodemo causes severe texture clipping. So I ended up using 08000000 instead, with no pointer to the texture file in the landtable and it seems to give me the same results. At least it's using the table now. The 02000000 must've been an old flag or something that's no longer recognized. This flag actually determines what to do with the stage textures, so since 02000000 wasn't a valid flag it never passed the condition needed to get into the function that loaded the files via the stage texture file table. The jury's still out on what to do with the background files though, but maybe I can adjust the stage texture file table entry for Windy Valley to load up the backgrounds that way. Or maybe I can use the object texture file table, since maybe the game sees the backgrounds as stage objects? I'll have to do more testing...
Whoops, four-month old bump. Let me start by saying that this is absolutely phenomenal - even now, three years later, I'm finding it pretty amazing to think we went from "The level's here but we can't do anything with it," to getting just the geometry to load in SADX, then Dude's recreation, and now this. Fantastic stuff. Anyways! I should point out before saying this that I have pretty much no knowledge of SA1/SADX's internal mechanisms, so I don't know how levels work as such (what you can/can't do with the level geometry, how LandTables themselves work, etc.). Having said that, I've sorta had a thought at the back of my mind about this for a long while now that I was hesitant to throw out there for fear of sounding like an idiot. Namely, is it possible that Act 2 doesn't use a LandTable because Sonic Team intended for the individual platforms/level pieces to move around independently during gameplay? Not necessarily anything complex - maybe just something simple like bobbing up and down. To quote one of Darkspines' posts from 2014: The fact that the game handles this specific act in such a way suggests to me that there was some gameplay concept in mind that wouldn't be possible with the regular level geometry format. Considering that the act in question is inside a tornado where the level pieces are supposedly being thrown around by the strong winds, a logical explanation (to me) would be that things were supposed to move around a bit. It's like, 99% speculation, but it's been on my mind for a long time now, so eh. I suppose it doesn't really make much of a difference anyways, seeing as even if that's the reason for WV2's unique treatment, unless the code is still tucked away somewhere there's a very slim chance of restoring the behaviour.
I've wondered the same thing for a long time, especially since a LandTable doesn't exist. Personally, I don't think it was anything more than a plan they may have had initially given there's no footage of the Tornado section with the platforms moving. It's also possible they did move at one point, but it made the section too difficult or something, and it was canned. Purely speculation in all honesty. If I had to guess, I'd be willing to bet the latter is most likely true if they ever moved given the final doesn't replicate that behavior, and is instead just a standard LandTable.
I should point out that the level needn't have moved around constantly or anything, it might've just broken off into pieces, much like Sky Deck does in the final.
The wiki article on the Autodemo finally now has content on it, as promised in my initial sign-up post. />/>/>/> It is...long. Sources: This forum topic (all 43 pages of it) This TCRF article, which has some information not found here. Thank you for this info, JmTsHaW! Me watching videos from this topic side-by-side with videos from the final The rather granular level differences were largely from my own observations with a few from the TCRF article (for instance, Icecap). The cutscene differences were also virtually all stuff I saw as well. OP was NOT kidding when they said that there were differences every few seconds! :v:/>/>/>/> Most of the E-102 and Big observations were also my work. The article needs images. Lots and lots of images. Right now it is basically just a very long text list...I might add the stuff I have in in the future but at the moment I am quite burned out. In terms of information, I have seen mentions in this topic about Twinkle Park and Sky Deck, but no actual concrete differences or images to stare at; their sections are pretty bare compared to even Casinopolis. Have they been looked at since? I would like to ask a question that is somewhat related to this prototype: Is there any code or other data that hints at the character order being changed? When I was a child and we had this game, we also had the strategy guide, and in this strategy guide, Gamma's sections were placed before Big's sections. This is also true of the TGS leftovers in this build, in which Gamma is between Big and Amy in the Choose Your Buddy! graphical character menu. In the final of course, Gamma is the last character - after Big. I've never seen this change discussed anywhere, and it has stuck in my mind for over a decade now. Does anyone have any idea how/when (how close it was to this proto) this happened and why? I've been super quiet for a while on the forums due to me getting ready to hit the post limit, and I was unsure if I'd be able to implement the changes on the wiki while I'd be locked in Trial Member status. I hope I can eventually become a full-fledged member in the near future so I can continue on discussing things! />/>
