[MainMemory]

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?

[evilhamwizard]

MainMemory, on 09 August 2016 - 12:33 PM, said:

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:

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:

[Woofmute]

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.

[SoNick]

This is great work! Thank you for sharing your finds

[Jmtshaw]

evilhamwizard, on 09 August 2016 - 05:56 PM, said:

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:

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. />

[evilhamwizard]

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:

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:

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):

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...

This post has been edited by evilhamwizard: 06 September 2016 - 05:51 PM

[Qtheman]

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!

evilhamwizard, on 07 August 2016 - 03:24 AM, said:

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:

[...]

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 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:

darkspines35, on 01 June 2014 - 05:26 PM, said:

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.

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.

[darkspines35]

Qtheman, on 06 January 2017 - 05:41 AM, said:

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:

darkspines35, on 01 June 2014 - 05:26 PM, said:

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.

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.

[Neo]

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.

[SystemsReady]

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! />/>/>/> 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! />/>

This post has been edited by SystemsReady: 01 June 2017 - 06:20 PM

[Overlord]

SystemsReady, on 29 May 2017 - 02:08 AM, said:

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!

Wish granted. =P

Great work on all of this! The Autodemo is a fascinating snapshot of SA1's development and it's good it's being so heavily looked at.

[Lanzer]

SystemsReady, on 29 May 2017 - 02:08 AM, said:

The wiki article on the Autodemo finally now has content on it, as promised in my initial sign-up post. It is...long.

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! />

Holy shit! thats a level of detail I haven't seen in a while.

'Wiki Sysops' may be in your future here. (Maybe 'Researcher' too but I'm not sure if thats just locked to Oldbies).

This post has been edited by Lanzer: 29 May 2017 - 04:43 PM

[Energy]

That's a crazy wiki post. Thanks for all that. Really interesting reading.

I'm guessing there isn't an early version of Chao Adventure on the disc?
Also just reading that there is the level data for that Dragon boss is such a tease.

[Windii]

SystemsReady, on 29 May 2017 - 02:08 AM, said:

The wiki article on the Autodemo finally now has content on it, as promised in my initial sign-up post. />/>/>/> It is...long.

Sources:
[list]
[*]This forum topic (all 43 pages of it)
[*]The TCRF article that has some information not found here

Okay, I know you mean well, but I don't think it would hurt to credit JmTsHaW specifically for that TCRF article, as as he is responsible for documenting most of what's on it. Without his contribution I don't know how much longer that page would have stayed barren and lifeless so it's only fair to give proper credit.

[SystemsReady]

Thank you very much for the membership and kind words! I should really get around to adding images at some point...

Windii, on 01 June 2017 - 11:55 AM, said:

SystemsReady, on 29 May 2017 - 02:08 AM, said:

The wiki article on the Autodemo finally now has content on it, as promised in my initial sign-up post. />/>/>/>/>/> It is...long.

Sources:
[list]
[*]This forum topic (all 43 pages of it)
[*]The TCRF article that has some information not found here

Okay, I know you mean well, but I don't think it would hurt to credit JmTsHaW specifically for that TCRF article, as as he is responsible for documenting most of what's on it. Without his contribution I don't know how much longer that page would have stayed barren and lifeless so it's only fair to give proper credit.

My apologies! I wasn't sure which of the several people in the revision history was from here. I don't recall it being mentioned in this topic either - there was an offhand reference to the Hotel sign from the TCRF article, which tipped me off to its existence, but not who had written it. I could have also spaced on it, as it took me a year to slowly go through everything and it has been months since I last looked at this topic.

Thank you very much JmTsHaW! :D I'll go edit my post too, if necessary.