Just finding an excuse to bump the thread. I was looking at Windy Valley in SADXLVL2 (I know it's really for SADX but whatever) just to take a gander at the object placement and noticed that Act 1 is filled to the brim with objects. I have no idea if this is a mistake or if there really is supposed to be all these objects loaded on the map at once. The placement itself seems erratic but not random (rows of rings and other common objects are placed in the right spot and nothing appears outside/inside the level mesh for instance). I did say that this part of the level had a huge set file, so maybe it isn't a problem. Act 3 isn't this crazy with it's object layout. But I noticed that when I loaded that part of Windy Valley in SADXLVL2 that there were solid cubes and cylinders about the level. I recall that these displayed when using the debugger in SADX, something with collision I think. There are a whole bunch of cylinders gathered together on the right. I also wanted to ask how the Windy Valley conversion to SADX was coming along. It'd be nice if we could do a total conversion of the AutoDemo to SADX in the form of a mod that can be loaded with the SADXModLoader. I tried to work with the idea but I'm lost on how to write the code for the DLL to replace what's necessary for things to load (like loading the .c output of the vertexes and having the .dll load the landtable). I wanted to restore Twinkle Park and Skydeck to see what they looked like since they seem mostly intact in the AutoDemo (textures, etc). Of course they're still files from September so they don't load in the AutoDemo, which is why I propose we port them over to SADX instead.
Windy Valley is still stuck crashing, and nobody's been able to get it working. Also, MainMemory's AutoDemo Levels mod contains Speed Highway At Dawn along with the test levels. We planned to merge all the AutoDemo levels into one mod mostly because there would be spawn point conflicts if they were separate. Also, keep in mind that the item layout probably used an item list that differs quite a bit from the final. Speed Highway At Dawn for Knuckles has this issue, even from within the AutoDemo itself. There are billboards and fountains and crap everywhere because it wasn't updated for the newer item list that Sonic's layout uses. And I'm sure MainMemory could explain a few things about the mod loader *wink wink nudge nudge*
Unfortunately I haven't done a very good job of explaining the mod loader outside of file replacements, setting up all the necessary parts for a DLL requires a certain knowledge of both the C/C++ languages and SADX's workings that not everyone has. As far as LandTables go, it's just a matter of either #include'ing the code file generated by the struct converter or SALVL or pasting it directly in your code file, then setting up the pointer array to insert a pointer to your LandTable into the LandTable list.
Do both parts of Windy Valley crash? I take it both of them do. I'm not sure what method you're using to get the geometry and such in the game, but I've had similar luck using buildSADX. Of course the problem's I've had in the past were probably due to addressing, though. I'm guessing you've tried to use SADXModLoader as well. :\ The only thing I could think of is to eliminate each 'object' model that makes up the level mesh to find if there is an offending one somewhere. Other than that, no idea... I know that the object set file for the level is probably for something older than the PRS provided on the disc image, but I was making a point that there were an abnormally abundance of objects loaded on parts of the map. It's probably for foliage and misc stage decorations, but there are a lot. I just remembered too, the stage has water somewhere originally. But it doesn't look like your average water though... I recall the stage bin references more frames of animation for the water texture too...
Yeah, both parts... sort of. I seem to remember that the second part would at least make it ingame until you would see the geometry, then promptly crash. Could be mistaken, though. Yep, see post below. That had me suspecting it was texture related for a while, because I had run into this issue before with other levels, but even then I haven't managed to fix it, and nor has darkspines. I suspected it might also be the filter method applied to all the mesh, but I deleted all the mesh except for one chunk and changed the filter method there to no avail. As for putting it in SADX, what we did was found the address for the landtable, extracted it with... whichever tool it was that does that, and kinda just dropped it in to SADX. Rebuilt the executable though, haven't tried with the mod loader personally. Somebody else may have however. See post below some more. Yeah, I see what you mean. I suppose if compared to the footage we've seen, the stage is generally barren gameplay-wise, except for the rings and an enemy here or there. The item limit is 1023, so going overkill on scenery would certainly limit them everywhere else.
The last time we tried importing Windy Valley via the mod loader, it didn't crash, but the level was only visible from specific camera angles and completely nonsolid. That kind of error is much harder to diagnose.
I knew Windy Valley was pretty well filled from using the same method as you evilham. I also did some digging through the level to find most of the object models (Pretty sure I snagged some of the wrong addresses though). Anywho, since people were asking I can't remember if it was ever fully shown off, I'll post all the pictures of my "restoration," which Catley helped me with. Part 1: Part 2: (This is an attempt to get all of the models I found. It's not certain this is all, but it seems to be based on their location in the file.) Part 3: It's mostly just a matter of waiting on being able to import the stages into SADX and working on trying to bring in what objects we can. Actually I wrote an import script for Max (It's horrible and needs to be re-written really badly. It doesn't import quads either for some reason...and texture importing is...a very hard thing to do with this...) and I pulled up these levels in 3DS. They're the same as the final as far as I can tell. Nothing blatantly different from the final. I also did some digging on Casinopolis (When you found the unused stuff). I feel like the main lobby is just a roughed out vision of the project, like 3D concept art so to speak. We also know the original NiGHTS Pinball table is in there. It uses quads, so I've been unable to see it properly which sucks. I can say the level only has a few of its own objects in the object list and has about four or five textures (All exist in the final game, so it's not referencing anything we haven't seen the final version of). It's odd though given there's a picture of this stage with textures and whatnot. Makes me wonder just how early this pinball stage was scrapped.
Just throwing this out there (I don't really know a whole lot about the technical side of 3D models) but lightwave uses quads, maybe its possible to load them in there?
It's just my script won't import them, and I have yet to figure out why. I'm not that skilled at MaxScript anyway, I can just do stuff that will work and it's always horribly written haha. It's honestly not that big of a deal since the importer itself is complete shit though. It was just a means to see some of the levels without having to do some heavy modding to get them to work with MainMemory's tools.
Um, I dunno if anyone noticed this but..."ALIFE RACE"? A-Life is the dev term for Chao (name comes from the concept as developed for NiGHTS, whatever those pudgy angel things were called), so...some hope that Chao Races were here already?
Those were discussed pages ago. We have one never before seen Chao Garden and another scrapped one (Egg Carrier and Mystic Ruins) and a fairly different Station Square Chao Garden as well as a different theme. The Chao Race isn't able to be opened I don't think, so I'm not sure if it's different or the same. Also, A-Life, as far as I knew, meant Artificial-Life and has always been used to mean the Chao since they are a type of artificial life. Edit: And those pudgy angel beings are called Nightopians for future reference.
It's a normal level. It's part of Windy Valley and would have been playable once upon a time. You can see Tails in it through some screenshots and video from the unveiling. Some of the textures from it survived inside the Chao Race however. The only other link is that a piece of Part 3 seemed to be the base for one of the unused Chao Gardens.
Actually, the Chao Race is present and loadable in the AutoDemo, no textures though. But it doesn't crash for some reason. It could be because there aren't any objects or object code if I recall. By the way I neglected to mention that Demul actually has a debugger where you can trace, step, and modify the PC and registers. It's a pain in the butt and really finicky but it works, only in interpreter mode though. They released the source code for the emulator a few months a go, but there was an older version compiled with the debugger that you can grab here.. Might be useful for tracking down where these levels are crashing. I actually got the object debugger to display for a brief moment once before it closed out of itself by messing around with the program counter. I could never get it to load again though. /> And a thought, is Ninja a common library that DC games use? Maybe we could create a signature for the Dreamcast libraries and scan 1ST_READ with them in IDA Pro or something. Maybe we could do this to find functions that are part of the library and make note of their addresses, then see how the levels/object make use of them. I'm starting to wonder if it could be feasible to fix Windy Valley and other levels to run in the AutoDemo just by fixing the addresses that point outside of the file (to 1ST_READ) so that they point to the correct ones. Disassemble the object code in the retail Windy Valley and compare it to the AutoDemo. I don't know how many objects are identical in both versions though, the prototype version seems to have a lot more objects than the final one. Bah.
It's in the Dreamcast Katana SDK, so I imagine many games, especially first party ones, would use it.
Hmm, found these strings at the end of STG00.bin (the test level). Google translate: No idea what this is for. Near the end of the file there are offsets to these strings, which is how I found them. Nothing uses the offsets though... I'm currently going to attempt at fixing Windy Valley so it loads up in the AutoDemo. I'm thinking that the game can at least load the land table/mesh/etc if there wasn't any code to look at (like the test map). I want to nop out everything in the beginning of the file until the file lists the textures and modify the object list to include only a few objects. Then replace the set file with something simple. The offset for the land tables will still be the same, so the file will still be the same size as the original but without all the stuff that might be causing problems. I might have to modify some stuff in 1ST_READ though, since there might be some offsets listed that point to a specific place in the stage file to start at. I could also try what I was doing before with the test map and just replace all the loading subroutine offsets in the objectlistentry struct with the address of a ring, heh. I doubt it's going to work because it's an amateur job, but that'd be great if it managed to load something up. I'm assuming the game doesn't care if it can't load textures (judging by the Chao Race map, the kart race, etc).
Did you check in 1ST_READ.BIN? If those are meant to be hint messages from Tikal or a hint monitor, the list of pointers for all the levels would be there.
I checked it quick and I can't find anything in 1ST_READ that looks at these addresses. :S I can't seem to find anything like this in the other stage files either. At a quick glance anyway. By the way, as far as porting objects go. With the current SADXModLoader, would it be relatively simple to port objects over that don't really have any logic to them? For Windy Valley there are a lot of simple objects like grass and stuff that could be ported over easily since it looks like all the loading subroutines do is just load up the object's model data. Like these: Code (Text): ROM:0C902CE0 ; =============== S U B R O U T I N E ======================================= ROM:0C902CE0 ROM:0C902CE0 ; Attributes: noreturn ROM:0C902CE0 ROM:0C902CE0 Load_WKi1: ; DATA XREF: ROM:stru_CA58F10o ROM:0C902CE0 mov.l dword_C902D64, r2 ; h'8C04AB98 ROM:0C902CE2 mov.l off_C902D7C, r3 ; off_CA47F7C ROM:0C902CE4 mov.l @(h'20,r4), r5 ROM:0C902CE6 jmp @r2 ROM:0C902CE8 mov.l r3, @(8,r5) ROM:0C902CE8 ; End of function Load_WKi1 ROM:0C902CE8 ROM:0C902CEA ROM:0C902CEA ; =============== S U B R O U T I N E ======================================= ROM:0C902CEA ROM:0C902CEA ; Attributes: noreturn ROM:0C902CEA ROM:0C902CEA Load_Wki2: ; DATA XREF: ROM:stru_CA58F10o ROM:0C902CEA mov.l dword_C902D64, r2 ; h'8C04AB98 ROM:0C902CEC mov.l off_C902D80, r3 ; off_CA466F0 ROM:0C902CEE mov.l @(h'20,r4), r5 ROM:0C902CF0 jmp @r2 ROM:0C902CF2 mov.l r3, @(8,r5) ROM:0C902CF2 ; End of function Load_Wki2 ROM:0C902CF2 ROM:0C902CF4 ROM:0C902CF4 ; =============== S U B R O U T I N E ======================================= ROM:0C902CF4 ROM:0C902CF4 ; Attributes: noreturn ROM:0C902CF4 ROM:0C902CF4 Load_WKusa1: ; DATA XREF: ROM:stru_CA58F10o ROM:0C902CF4 mov.l dword_C902D64, r2 ; h'8C04AB98 ROM:0C902CF6 mov.l off_C902D84, r3 ; off_CA48190 ROM:0C902CF8 mov.l @(h'20,r4), r5 ROM:0C902CFA jmp @r2 ROM:0C902CFC mov.l r3, @(8,r5) ROM:0C902CFC ; End of function Load_WKusa1 ROM:0C902CFC ROM:0C902CFE ROM:0C902CFE ; =============== S U B R O U T I N E ======================================= ROM:0C902CFE ROM:0C902CFE ; Attributes: noreturn ROM:0C902CFE ROM:0C902CFE Load_Grass1: ; DATA XREF: ROM:stru_CA58F10o ROM:0C902CFE mov.l dword_C902D64, r2 ; h'8C04AB98 ROM:0C902D00 mov.l off_C902D88, r3 ; off_CA48404 ROM:0C902D02 mov.l @(h'20,r4), r5 ROM:0C902D04 jmp @r2 ROM:0C902D06 mov.l r3, @(8,r5) ROM:0C902D06 ; End of function Load_Grass1 ROM:0C902D06 ROM:0C902D08 ROM:0C902D08 ; =============== S U B R O U T I N E ======================================= ROM:0C902D08 ROM:0C902D08 ; Attributes: noreturn ROM:0C902D08 ROM:0C902D08 Load_Grass2: ; DATA XREF: ROM:stru_CA58F10o ROM:0C902D08 mov.l dword_C902D64, r2 ; h'8C04AB98 ROM:0C902D0A mov.l off_C902D8C, r3 ; off_CA48688 ROM:0C902D0C mov.l @(h'20,r4), r5 ROM:0C902D0E jmp @r2 ROM:0C902D10 mov.l r3, @(8,r5) ROM:0C902D10 ; End of function Load_Grass2 ROM:0C902D10 ROM:0C902D12 ROM:0C902D12 ; =============== S U B R O U T I N E ======================================= ROM:0C902D12 ROM:0C902D12 ; Attributes: noreturn ROM:0C902D12 ROM:0C902D12 Load_Grass3: ; DATA XREF: ROM:stru_CA58F10o ROM:0C902D12 mov.l dword_C902D64, r2 ; h'8C04AB98 ROM:0C902D14 mov.l off_C902D90, r3 ; off_CA48A2C ROM:0C902D16 mov.l @(h'20,r4), r5 ROM:0C902D18 jmp @r2 ROM:0C902D1A mov.l r3, @(8,r5) ROM:0C902D1A ; End of function Load_Grass3 ROM:0C902D1A ROM:0C902D1C ROM:0C902D1C ; =============== S U B R O U T I N E ======================================= ROM:0C902D1C ROM:0C902D1C ; Attributes: noreturn ROM:0C902D1C ROM:0C902D1C Load_Grass4: ; DATA XREF: ROM:stru_CA58F10o ROM:0C902D1C mov.l dword_C902D64, r2 ; h'8C04AB98 ROM:0C902D1E mov.l off_C902D94, r3 ; off_CA48C20 ROM:0C902D20 mov.l @(h'20,r4), r5 ROM:0C902D22 jmp @r2 ROM:0C902D24 mov.l r3, @(8,r5) ROM:0C902D24 ; End of function Load_Grass4 8C04AB98 seems like it could be the address of a subroutine in an older 1ST_READ, the off_whatever stuff are offsets to offsets of OBJECT structs.
The only limit to what can be done is the knowledge of the hacker. You'd likely want to find an existing object in SADX that only displays a model, and base it on that. There's probably a set of objects that behave just like that already, storing a model pointer and jumping to a common routine.
