(DC) Sonic Adventure Prototype (1998-10-16) Everything you need to know + download link inside.
#631
Posted 09 August 2016 - 12:33 PM

#632
Posted 09 August 2016 - 05:56 PM

MainMemory, on 09 August 2016 - 12:33 PM, said:
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:

#633
Posted 09 August 2016 - 06:57 PM

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.
#635
Posted 10 August 2016 - 12:09 PM

evilhamwizard, on 09 August 2016 - 05:56 PM, said:
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.

#636
Posted 06 September 2016 - 12:49 AM



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...
#637
Posted 06 January 2017 - 05:41 AM

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:
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:
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.
#638
Posted 06 January 2017 - 10:32 PM

Qtheman, on 06 January 2017 - 05:41 AM, said:
To quote one of Darkspines' posts from 2014:
darkspines35, on 01 June 2014 - 05:26 PM, said:
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.
#639
Posted 07 January 2017 - 10:56 AM

#640
Posted 29 May 2017 - 02:08 AM


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!

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!

#641
Posted 29 May 2017 - 01:46 PM

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

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.
#642
Posted 29 May 2017 - 04:39 PM

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!

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).
#643
Posted 01 June 2017 - 07:57 AM

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.
#644
Posted 01 June 2017 - 11:55 AM

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

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.
#645
Posted 01 June 2017 - 06:18 PM

Windii, on 01 June 2017 - 11:55 AM, said:
SystemsReady, on 29 May 2017 - 02:08 AM, said:

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.