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. Code (Text): 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. Code (Text): 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.
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?
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.
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.
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.
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.
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.
Im referring to working with Sonic 2, so the tiles for normal and super/hyper are in the same files. What I mean is I will load up the files and import a new sprite. When I do that it's already garbles, so I manually fix it and save it. When unloading then reloading the files, the sprite loads up with the correct size mappings, but the tiles will be from another sprite in the set.
Can anyone please tell me what editor I need to import SADX level models? I found out the hard way that SADXMDL only really works for object models... (I tried going to a level location and it crashes, but when I edited Knuckles' model it worked perfect...) EDIT: ...and its part of SonicLVL...wow...I am such an idiot sometimes...well, at least I can finally have fun screwing around with Sonic Adventure... EDIT2: Yeah, I've been trying to get the wrong program to work all this time...that must have been why I had so much trouble...
More S3+K questions: 1. I've tried to code in my hammer move into Sonic 3 like so: Code (Text): Sonic_Hammer: cmp.b #$24,$20(a0) bne.s lol7 bset #1,(Ctrl_1_locked).w move.w $1C(a0),d0 move.w d0,d1 asr.w #3,d1 sub.w d1,d0 move.w d0,$1C(a0) rts lol7: btst #1,(Ctrl_1_logical).w ; is Down button pressed? bne.s JmpTo_SonicHammerreturn ; if yes, return btst #6,(Ctrl_1_pressed_Logical).w ; is A button pressed? beq lol ; if not branch tst.b ($FFFFFFA4).w ; was jumpdash flag set? bne.w JmpTo_SonicHammerreturn ; if yes, branch move.b #1,($FFFFFFA4).w ; if not, set jumpdash flag move.b #$24,$20(a0) ; show hammer animation jmp Hammer_Cont JmpTo_SonicHammerreturn: jmp Sonic_Hammer_return Hammer_Cont: move.w (a0),d0 btst #0,$22(a0) beq lol8 neg.w d0 lol8: cmp.w #$400,d0 bgt lol move.w #$400,d0 btst #0,$22(a0) beq lol9 neg.w d0 lol9: move.w d0,$1C(a0) lol: move.w $18(a0),d0 tst.w d0 bpl label neg.w d0 label: cmpi.w #$600,d0 bgt Sonic_Hammer_Return btst #6,(Ctrl_1_pressed_logical).w ; is A button pressed? beq.b Sonic_Hammer_return ; if not, return move.b #$24,$20(a0) ; show animation $20 move.w #$47,d0 ; play sound jsr (Play_Sound_2).l Sonic_Hammer_return: bclr #1,(Ctrl_1_locked).w ; unlock controls rts ; End of function Sonic_Hammer It works okay except for one problem, it 'nudges' the player forward, however it doesn't always direct properly to where the player is facing (eg. if facing right you're pulled backwards). 2. Anyone know how to turn off the shield moves for Sonic and have him use the insta shield all the time?
1. Looking through your code, it seems that it's missing a check to see if the player is facing a certain direction, which is possibly the cause of this. The same thing happened to me when I first coded Knuckles' Slide Punch (see the General Video/Screenshot thread for my S3K hack) and testing if Knuckles is facing left, then negating his inertia fixed the problem. (Address $2A is the player's current direction. 2. The shields graphics override Sonic's Insta-shield, so once he collects a shield until that bitfield is cleared (if it's destroyed) the insta-shield can't load. So I'm not sure if that's possible. :\
Quick question. I have been twisting my mind for hours trying to figure this out. I am using the S1 (Megadrive) merc version and am trying to initiate a palette change within gameplay. I have tried copying small samples of code from various places within the main code but I either get illegal errors or non-compiling. I am trying to implement it into an object code, Imagine that you collect a ring and it makes the palette a shade darker - or something along those lines. Thanks
Wholly untested, but based on what I know about that area... You can get this behaviour by commenting out everything from loc_1192C down to, and including, the first two lines under loc_119F6. That will mean you can instashield during invincibility too, and it will even prevent super transformation in favour of instashield. (I'd recommend just commenting everything except for the label lines themselves in case you find other code jumps in here.) If you want the invincibility block back, uncomment the first two lines under loc_1192C again. If you want Super transformation back, uncomment from loc_119D2 to right before the loc_119F6 label. (You still want to keep those first two lines of loc_119F6 commented as they will forcibly block use of instashield when any other shield is present.) Ravenfreak is quite correct in saying that the instashield will look completely wrong if you have a shield, invincibility, super transformation etc. If you wanted to fix that, you can do so with some trickery within the shields themselves to swap their map/DPLC dynamically, but that can get interesting, based on my experience of doing this with the classic shield. I'm guessing your goal is to make the hammer move for Amy not get overridden by a shield move, though, in which case this should more or less do the trick.
What I was thinking was that I could edit the insta shield animation to use the hammer's hearts which may at least mean Amy's sprite uses less tiles by itself. What exactly are the insta shield's properties? Does it only make Sonic invincible or does it increase his attack radius? Could it be possible to attach to another non jumping animation or action? Thanx for all the help from both of you. I'll give these a shot.
Hmm, could be useful to me. Might take a gander at the insta shield's coding and see what else I can edit.
