Sonic and Sega Retro Message Board: (DC) Sonic Adventure Prototype (1998-10-16) - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 44 Pages +
  • ◄ First
  • 40
  • 41
  • 42
  • 43
  • 44
    Locked
    Locked Forum

(DC) Sonic Adventure Prototype (1998-10-16) Everything you need to know + download link inside.

#616 User is offline sonicblur 

Posted 27 July 2016 - 07:10 PM

  • Posts: 1240
  • Joined: 18-February 08
  • Gender:Male
  • Wiki edits:6
Regarding getting the textures... I read over the explanation twice and I'm not completely clear as to what you're asking. The unknown values, are they an obstacle to getting things to work or can you just use the most common values seen for those at the moment? Perhaps they're display related parameters?

Or is your biggest obstacle just knowing which textures to pack into each ID? If so, didn't Dude need to ultimately solve that manually too? If that's the case, then you just need some dummy textures which are images of the hex ID's of the texture it represents. Look at screenshots and fill in the missing numbers until you've found them all. That seems to be the only way to do it without the original data, or am I missing something?

I can run GD-ROM images on hardware if it's useful for some reason.

#617 User is offline evilhamwizard 

Posted 27 July 2016 - 07:46 PM

  • Posts: 1285
  • Joined: 16-June 04
  • Gender:Male
  • Wiki edits:109

View Postsonicblur, on 27 July 2016 - 07:10 PM, said:

Regarding getting the textures... I read over the explanation twice and I'm not completely clear as to what you're asking. The unknown values, are they an obstacle to getting things to work or can you just use the most common values seen for those at the moment? Perhaps they're display related parameters?

Or is your biggest obstacle just knowing which textures to pack into each ID? If so, didn't Dude need to ultimately solve that manually too? If that's the case, then you just need some dummy textures which are images of the hex ID's of the texture it represents. Look at screenshots and fill in the missing numbers until you've found them all. That seems to be the only way to do it without the original data, or am I missing something?

I can run GD-ROM images on hardware if it's useful for some reason.


Heh, it's all pretty complicated to explain unless you look at the disassembly itself. It's not pretty, and it's difficult to comprehend unless you go through the disassembly like I have. The only thing I'm unsure of are these two bytes when referring to the pointers of the stage texture files:

seg001:8C191050 StageTex_Beach01:.data.b 0 ;act number              ; DATA XREF: seg001:tbl_stagetexturefileso
seg001:8C191051                 .data.b    1 ; field number
seg001:8C191052                 .data.b    1 ;don't understand this byte
seg001:8C191053                 .data.b    0 ;don't understand this byte


I'm pretty sure it wont be a major problem since I can just look onto the final build to see what it's doing for Windy Valley. Since the AutoDemo doesn't have the texture files (either on the disc or referenced in 1st_read) I have to add the references back manually by creating copies of the tables that refer to the stage/object textures. Overall it's not that difficult to pull off. The only thing that might be a significant problem are loading the background textures, since those are loaded into the game by a subroutine within Windy Valley's stage file that is called only by an external function in 1st_read (in other words, not in a table like anything else). I don't know if the AutoDemo will still try to load the subroutine in the stage file or if it's been removed somehow. But I think I can figure it out in time.

What I need are actual textures to work with though, since I don't really have anything to use and I'm not much of an artist. I was thinking of trying something like you said and what Catley and darkspines35 did earlier and just replicate the texture files with temp textures that contain an image of the ID value and just go from there. That would at least help me test to see if my methods are working as intended.
This post has been edited by evilhamwizard: 27 July 2016 - 07:50 PM

#618 User is offline sonicblur 

Posted 27 July 2016 - 10:15 PM

  • Posts: 1240
  • Joined: 18-February 08
  • Gender:Male
  • Wiki edits:6

View Postevilhamwizard, on 27 July 2016 - 07:46 PM, said:

What I need are actual textures to work with though, since I don't really have anything to use and I'm not much of an artist. I was thinking of trying something like you said and what Catley and darkspines35 did earlier and just replicate the texture files with temp textures that contain an image of the ID value and just go from there. That would at least help me test to see if my methods are working as intended.

Do you need someone to convert all of the textures from Dude's mod to Dreamcast PVR format?
Or do you need images with Hex codes on them? There are websites that can do this for you, example:
http://dummyimage.co...fff.png&text=F2

Just trying to help in any way I can, without having to study the disassembly.

#619 User is offline Dude 

Posted 27 July 2016 - 10:54 PM

  • Posts: 3137
  • Joined: 11-September 04
  • Gender:Male
  • Location:Southbridge, MA
  • Project:Random VR/AR trash
  • Wiki edits:43

View Postevilhamwizard, on 05 December 2015 - 01:06 AM, said:

Misc 'static' objects - flowers, bushes, rocks, etc:

The interesting thing to note is the animation applied to everything. I don't think this was seen in Dude's restoration. All the plants rattle in the wind, which is bizarre to see without textures. It's definitely not an error because of the bad textures.


This is correct. I didn't port any code or behavior from the AutoDemo to the restoration. Objects without suitable replacements in the final version had their models ripped, and I duplicated and positioned them according to the SET file using a script. If they needed collision, I modeled that myself and also baked it into the world geometry. The object models were then baked into the final level geometry. Anything that required animation or custom code didn't survive. Much like the Spring Rock you mentioned. I'm actually surprised at how accurate my results were, looking at the things like the low rock-walls that hug the edges of the stage and the little signs that flap in the wind (although mine don't flap). Everything seems to be aligned and placed roughly the same.

View Postevilhamwizard, on 05 December 2015 - 01:06 AM, said:

"Baneiwa" or "Spring Rock":
The early version of Windy Valley sported a unique floating blue version of the spring. This spring, unlike the normal common spring, isn't as sensitive to the player's touch. You have to literally jump on the top to be pushed outward. I recall seeing a video of this in action in a press conference or advert and the player was pushed outward much more calmly than this. It might have something to do with the parameters the stage's set file gives to the object that affects the velocity it pushes the player. The object set file for this stage was originally for a much early version than the actual stage file, so the objects coding were probably tweaked quite a bit since then.


The video you saw was running at half speed. Everything was slowed down. That's why the spring animation looked so much calmer.

Good work btw. Hopefully these videos will show people how big of a restoration actually had to be done to get things playable, let alone the 'completed level' state that it finally ended up in. I really wish I'd had these videos when I was working on it, although I probably still wouldn't have been able to get any of the object code ported.

#620 User is offline Jmtshaw 

Posted 28 July 2016 - 03:00 PM

  • Posts: 97
  • Joined: 12-September 10
  • Gender:Not Telling
Nice to see that stuff is still being found in this thing after 3 years.

I've been lurking this topic since the day it was made but hadn't really gotten the chance to post until now. I know it's already been mentioned here once already, but I wrote an article on TCRF the other week with most of the stuff that can be found including a lot of the things that were discovered in this thread. There's still a lot of info missing from it but as far as I know it's mostly stuff to do with objects, such as what's going here now with Windy Valley along with other stages like Twinkle Park and Sand Hill.

View Postevilhamwizard, on 23 July 2016 - 08:42 PM, said:

I didn't bother with fixing these yet. But it's interesting to note that TakoW is the tornado, which for some reason isn't referenced at all in act 1's set file.

Dunno if this has been talked about yet, but is this used anywhere? It's listed as TAKO W, at least in SA Tools. Don't know all that much about going deeper myself.

But regardless, looking forward to seeing what else can be dug up here.


EDIT: Not really worth making a new post but here's the RAM addresses for the FPS if anyone wants them: 8C75D0A8 / 8C75D0B0.
Kinda curious to see how Windy Valley would run at 60 FPS, seeing as how it already seems to slow down considerably with all those objects.
This post has been edited by Jmtshaw: 28 July 2016 - 08:19 PM

#621 User is offline evilhamwizard 

Posted 28 July 2016 - 06:48 PM

  • Posts: 1285
  • Joined: 16-June 04
  • Gender:Male
  • Wiki edits:109

View PostJmtshaw, on 28 July 2016 - 03:00 PM, said:

View Postevilhamwizard, on 23 July 2016 - 08:42 PM, said:

I didn't bother with fixing these yet. But it's interesting to note that TakoW is the tornado, which for some reason isn't referenced at all in act 1's set file.

Dunno if this has been talked about yet, but is this used anywhere? It's listed as TAKO W, at least in SA Tools. Don't know all that much about going deeper myself.

But regardless, looking forward to seeing what else can be dug up here.


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.

View Postsonicblur, on 27 July 2016 - 10:15 PM, said:

View Postevilhamwizard, on 27 July 2016 - 07:46 PM, said:

What I need are actual textures to work with though, since I don't really have anything to use and I'm not much of an artist. I was thinking of trying something like you said and what Catley and darkspines35 did earlier and just replicate the texture files with temp textures that contain an image of the ID value and just go from there. That would at least help me test to see if my methods are working as intended.

Do you need someone to convert all of the textures from Dude's mod to Dreamcast PVR format?
Or do you need images with Hex codes on them? There are websites that can do this for you, example:
http://dummyimage.co...fff.png&text=F2

Just trying to help in any way I can, without having to study the disassembly.


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.

View PostDude, on 27 July 2016 - 10:54 PM, said:

Good work btw. Hopefully these videos will show people how big of a restoration actually had to be done to get things playable, let alone the 'completed level' state that it finally ended up in. I really wish I'd had these videos when I was working on it, although I probably still wouldn't have been able to get any of the object code ported.


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.

Posted Image
This post has been edited by evilhamwizard: 28 July 2016 - 06:51 PM

#622 User is offline MainMemory 

Posted 28 July 2016 - 07:25 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4247
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339

View Postevilhamwizard, on 27 July 2016 - 07:46 PM, said:

Heh, it's all pretty complicated to explain unless you look at the disassembly itself. It's not pretty, and it's difficult to comprehend unless you go through the disassembly like I have. The only thing I'm unsure of are these two bytes when referring to the pointers of the stage texture files:

seg001:8C191050 StageTex_Beach01:.data.b 0 ;act number              ; DATA XREF: seg001:tbl_stagetexturefileso
seg001:8C191051                 .data.b    1 ; field number
seg001:8C191052                 .data.b    1 ;don't understand this byte
seg001:8C191053                 .data.b    0 ;don't understand this byte


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.

#623 User is offline McAleeCh 

Posted 03 August 2016 - 09:42 AM

  • Posts: 899
  • Joined: 12-January 03
  • Gender:Male
  • Wiki edits:27
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. = )
This post has been edited by McAleeCh: 03 August 2016 - 09:43 AM

#624 User is offline Alex Hofstadter 

Posted 03 August 2016 - 09:54 AM

  • Posts: 15
  • Joined: 29-December 14
  • Gender:Male
  • Location:Chile
  • Project:It's a secret
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
This post has been edited by Alex Hofstadter: 03 August 2016 - 09:55 AM

#625 User is offline Orengefox 

Posted 04 August 2016 - 10:40 PM

  • The world's greatest scientist and soon to be the world's greatest pervert.
  • Posts: 454
  • Joined: 25-May 04
  • Gender:Male
  • Location:Right in front of my computer.
  • Project:Some artwork, a ZZT game, and a hack.
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].

View PostOrengefox, on 04 August 2016 - 08:29 AM, said:

Posted Image
PROTO-TWINKLE-MOTHER-FUCKING-PARK-BABY!

View PostJmtshaw, on 04 August 2016 - 12:08 PM, said:

In terms of SA1. seeing what was shown of Twinkle Park those ships look really interesting. For one, they're swinging instead of raising up and down. The camera angle as Sonic goes around the ship on the left is also different (facing towards it rather than away from it) and of course, the ships also look very different to how they appear in the final game. I'm very curious as to whether this is the same case in the AutoDemo or not.

View Postsonicblur, on 04 August 2016 - 07:42 PM, said:


This post has been edited by Orengefox: 04 August 2016 - 10:41 PM

#626 User is offline evilhamwizard 

Posted 07 August 2016 - 03:24 AM

  • Posts: 1285
  • Joined: 16-June 04
  • Gender:Male
  • Wiki edits:109

View PostMcAleeCh, on 03 August 2016 - 09:42 AM, said:

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.


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:

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
Posted Image

CAA4E64:
Posted Image

CAADBE4
Posted Image

CAA6198
Posted Image

CAA70FC
Posted Image

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.
This post has been edited by evilhamwizard: 07 August 2016 - 03:33 AM

#627 User is offline evilhamwizard 

Posted 08 August 2016 - 02:05 PM

  • Posts: 1285
  • Joined: 16-June 04
  • Gender:Male
  • Wiki edits:109
Double posting because I finally finished importing all the code for this stage file. And I got this to load :)/> :

Posted Image

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.

#628 User is offline Overlord 

Posted 08 August 2016 - 02:42 PM

  • Substitute Meerkovo IT Chief
  • Posts: 17146
  • Joined: 12-January 03
  • Gender:Male
  • Location:Berkshire, England
  • Project:VGDB
  • Wiki edits:3,204
The progress you're making with this is fantastic to see - great job.

#629 User is offline Ayu Tsukimiya 

Posted 08 August 2016 - 06:05 PM

  • UGUU~
  • Posts: 479
  • Joined: 26-April 10
  • Gender:Male
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.

#630 User is offline Neo 

Posted 09 August 2016 - 03:39 AM

  • Not actually a clacker or a jack
  • Posts: 1407
  • Joined: 10-December 04
  • Gender:Male
  • Location:Portugal
  • Project:Sonic 3 Unlocked
  • Wiki edits:1
Too cool. I hope the reason they redid the level was due to performance issues -- this version is SO much more interesting.

  • 44 Pages +
  • ◄ First
  • 40
  • 41
  • 42
  • 43
  • 44
    Locked
    Locked Forum

2 User(s) are reading this topic
0 members, 2 guests, 0 anonymous users