[Turbohog]

Has anyone ever successfully ripped the level geometry for Sonic Heores/Shadow? If so, how did they manage to convert the .bsp files? Or did they upload them somewhere? :P

[KingofHarts]

I come with not a question, but possibly an answer. (I take no credit for this... I had ZERO to do with it, just posting so others may know where to look.)

I was recently speaking to RHS about his ASM guide, and he directed me to a newer, more accurate guide by our beloved MarkeyJester.
EDIT: I took the link down. Apparently I was told I probably shouldn't post it yet. (Not by Markey, rather... Someone else) the person who told me is an experienced member and I trust his judgment. That said, anyone who wants to find this guide can just google search MJ ASM guide... Or something like that. That's how I got there, and if another trusted source is telling me this much, I'm sure it's alright.
Markey OKed it... so here it is again: http://mrjester.hapisan.com/04_MC68/
I'll warn you now though... Markey is NOT finished with this guide just yet, so not everything is up to snuff just yet... BUT I'm using it, and, if my two cents is worth anything... its a damned good guide so far. So check it out.

This post has been edited by KingofHarts: 29 March 2012 - 01:57 PM

[KingofHarts]

Hello one and all. I'm asking about Sonic 1, so anyone who is good with this game,..

I'm trying a bugfix. Trying to fix the GHZ Act 1 bug that kills you if you go too quickly down the S tunnels. I modified it so that the screenlimit moves down once the camera's xposition reaches the checkpoint (1700), instead of the second S tunnel (1780). Is this the correct way to go about fixing this?

I tested it, and I'm not dying... but I just wanna make sure I actually corrected what caused the bug, or if I was missing something...?

Could you tell me?

[Mercury]

KingofHarts, on 30 March 2012 - 10:44 PM, said:

Hello one and all. I'm asking about Sonic 1, so anyone who is good with this game,..

I'm trying a bugfix. Trying to fix the GHZ Act 1 bug that kills you if you go too quickly down the S tunnels. I modified it so that the screenlimit moves down once the camera's xposition reaches the checkpoint (1700), instead of the second S tunnel (1780). Is this the correct way to go about fixing this?

I tested it, and I'm not dying... but I just wanna make sure I actually corrected what caused the bug, or if I was missing something...?

Could you tell me?

Your fix should do the trick, but here's what I did:

(Copy paste from my never released ReadySonic guide)

Quote

There are a few camera bugs in Sonic 1 that you might want to take care of.

The Solution:

First, Sonic can die in the S-tunnel in GHZ1 if he's moving fast enough. The slowly changing bottom boundary can't catch up with him fast enough. This is of particular concern if you enable the Spindash. We can fix this easily enough.

In _incObj\Sonic LevelBound.asm, Sonic_LevelBound, @chkbottom replace this line:

move.w (v_limitbtm2).w,d0

with this one:

move.w (v_limitbtm1).w,d0

This way Sonic will only die if he touches the intended level boundary, not the current one (which can take some time to catch up).

This works great, and it will certainly avoid a lot of headache, but you might still not like the fact that, visually, the camera still takes too long to catch up. The solution for this is easy enough, too.

In _inc\DynamicLevelEvents.asm, DLE_GHZ1 add these lines:

move.w #$300,(v_limitbtm1).w ; set lower y-boundary
move.w #$300,(v_limitbtm2).w ; set lower y-boundary
cmpi.w #$1780,(v_screenposx).w ; has the camera reached $1780 on x-axis?
bcs.s locret_6E08 ; if not, branch
move.w #$400,(v_limitbtm1).w ; set lower y-boundary
move.w #$400,(v_limitbtm2).w ; set lower y-boundary

What we've done is set "v_limitbtm2" both times "v_limitbtm1" is set, so that the boundary changes instantaneously rather than taking a moment to catch up. At this particular instance, there's no problems with doing that.

There is a bug in GHZ3 that our first fix causes, though. To fix it, at DLE_GHZ3main, loc_6E8E add these two lines:

loc_6E8E:
cmpi.w #$380,(v_screenposy).w
bcc.s locret_6E96

Sonic can still - if he leaps to the right of the spikes that come after the 5 Ring Monitors, Life Monitor and Yellow Spring - catch a glimpse of the underside of the zone. The waterfall doesn't finish, and it looks kind of dippy (this is actually possible under certain circumstances even without our camera fix). I've added a graphical fix in ReadySonic by extending the waterfall tiles; it's up to you to solve the issue however you prefer.

[Caniad Bach]

Is anyone here well versed in VGM Music Maker? I can't figure out how to make a prolonged note!

[E-122-Psi]

I've had problems building the S3 dissassembly (most recent version), I can't find most of Super Sonic's data (eg. mappings, PLCs) and it doesn't recognise any of their coding in the asm (I only managed to get it to build by redirecting it to Sonic's normal data right now). Any idea what's wrong?

Also some other questions about Sonic's data:

Anyone know where the mappings for his 'extra' sprites are?

Is it possible to make his sprite number go beyond $FF?

[Cyrus]

Edit: trash please

This post has been edited by Cyrus: 03 April 2012 - 11:55 PM

[Tiddles]

E-122-Psi, on 31 March 2012 - 08:19 PM, said:

I've had problems building the S3 dissassembly (most recent version), I can't find most of Super Sonic's data (eg. mappings, PLCs) and it doesn't recognise any of their coding in the asm (I only managed to get it to build by redirecting it to Sonic's normal data right now). Any idea what's wrong?

Also some other questions about Sonic's data:

Anyone know where the mappings for his 'extra' sprites are?

Is it possible to make his sprite number go beyond $FF?

The labels are PLC_SuperSonic and Map_SuperSonic, and they are contained within the same files as the normal Sonic data (Map - Sonic.asm, Sonic pattern load cues.asm). This, of course, makes it a total pain to edit. SME can't cope with these files at all, and will not load all of the frames; if you resave the file, you then end up deleting the Map_SuperSonic and PLC_SuperSonic labels from those files, and most likely all the additional frames that should have come afterwards.

Perhaps if That One Jig stops by he'll have some insight on how he worked with the oldschool sprites. All I really know is that in the end he gave me binary mappings and DPLC to put in, and I referenced the Super stuff with an offset, e.g.

Map_Sonic:	binclude "General\Sprites\Sonic\Map - Sonic S1 S3C.bin"
Map_SuperSonic:	equ Map_Sonic+$1F6
PLC_Sonic:	binclude "General\Sprites\Sonic\Sonic pattern load cues S1 S3C.bin"
PLC_SuperSonic:	equ PLC_Sonic+$1F6

The "extra" mappings and PLC are just the last few frames in the main map/DPLC files. The code checks the mapping frame number to decide which art offset to load from; the last frames of the file will point to the "extra" art.

loc_12CD6:
		...
		move.l	#ArtUnc_Sonic,d6
		cmpi.w	#$1B4,d0
		bcs.s	loc_12CF8
		move.l	#ArtUnc_Sonic_Extra,d6

I can't say much about the sprite number because I haven't really looked at that area, but off the top of my head, I would think animation scripts and SSTs would be a problem because of referencing frame numbers with a single byte; therefore, I assume you would have to change a lot of data structures and change the code to work with that. But perhaps someone more familiar with these things has come up with a smarter answer.

[E-122-Psi]

Dammit. That probably explains why I got a working build until I used MapEd on it.

This puts me in a jam since my project basically revolves around editing a character to have lots of extra moves and animations. Might it be more ethical to make a new character slot rather than edit Sonic's?

[Tiddles]

Basing your character on Knuckles or Tails would at least solve the Super problem, since there are no separate DPLC or mappings to mess things up. I don't know if those files work better with SME. I can only hope so! You could also just remove any sections of code that reference use of different mappings/anims/DPLC for Super Sonic, though you would still need a way to edit the full set of frames (getting SME to open them from the original ROM is a good starting point.)

Building a new character slot is probably the cleanest thing to do in the long run, but would be a lot more work due to all the coding that does different things depending on various character IDs. "Blue Knuckles" is the result of feeding in a character ID the original game doesn't understand, and you know how mixed up that is! But Hayate managed to do this in Customizable, so it is certainly possible.

[E-122-Psi]

The character likely won't need unique Super sprites anyway (I already redirected the asm to Sonic's normal sprites). The best I can think of for the extras is creating a new mapping file from scratch and redirecting to it when neccessary. Would that maybe work?

I can get Knuckles and Tails' extra sprites to load on MapEd at least. Sonic's just seemed easier because his overall sprite design and layout better fits the character used compared to the other two, at least until I discovered all these complexities concerning his files inparticular.

By the way anyone know where Sonic's super pallette is?

Hayate's is pretty much exactly how I want to take the new character. He also seemed able to place in more sprites and animations somehow, suggesting my project is at least possible somehow.

[Tiddles]

E-122-Psi, on 02 April 2012 - 06:45 PM, said:

The character likely won't need unique Super sprites anyway (I already redirected the asm to Sonic's normal sprites). The best I can think of for the extras is creating a new mapping file from scratch and redirecting to it when neccessary. Would that maybe work?

I can get Knuckles and Tails' extra sprites to load on MapEd at least. Sonic's just seemed easier because his overall sprite design and layout better fits the character used compared to the other two, at least until I discovered all these complexities concerning his files inparticular.

By the way anyone know where Sonic's super pallette is?

Hayate's is pretty much exactly how I want to take the new character. He also seemed able to place in more sprites and animations somehow, suggesting my project is at least possible somehow.

You shouldn't need to do anything special like a separate map/DPLC for the extras. If you're not worried about the Super bits, I think it's really just a case of getting SME to load them in the first place; after that it should be able to resave them for you. You should be able to use Load from ROM on a Sonic & Knuckles ROM with the correct offsets to retrieve the DPLC and mappings. I can find those offsets for you later if you can't find them documented anywhere.

Once all the frames are loaded, you just have to be prepared for the extra ones to look stupid while you edit the normal ones; then, when you need to edit the extra frames, load up the extra art file in SME, and live with all the non-extra frames looking temporarily stupid.

As for animation frames, there are quite a few in there that are not used in the game, e.g. the whistling sequence. These can be safely repurposed. There are also duplicates here and there; I recall the standing pose appearing more than once - if you can change any references to these to point at just one instance, you can possibly reclaim those entries too.

[E-122-Psi]

Actually I tried adding new sprites at the end of the main Sonic mappings to make the Extra animations on MapEd. Though there is obviously a bit of fiddliness guessing the right positions for them, it actually pretty much fixes everything.

There are a few spare spaces, but it still only leaves around a dozen or so sprites free, I will likely need around FORTY or so.

[Hitaxas]

On the topic of SonMapED, I am also having issues. I am only up to sprite #ED and yet, I cannot get the mappings and DPLCs to save correctly. Every time I reopen the files, the latest sprite I have added contains the right mappings, but the incorrect tiles. It's really making it tough to add more animations.

[E-122-Psi]

Do you mean when you added the frames for the Extra file then loaded to the main file they were garbled? That will happen because they are on a separate file and MapEd will only load according the tiles loaded. So long as you saved the mappings with the Extra tiles loaded and placed there it should look fine in the game.

Oddly I did have this problem once though. I tried to add some new tiles to make more sprites but they always loaded as sprites from the original set. It seems to have problems recognising new tiles added onto the file.

Similarly I'm having problems altering the animation file, I can only change the animations so long as they keep the exact same number of figures, anything above or below leads to thousands of errors building. The S3+K dissassembly seems to be inflexible adding much new data onto it.