Still, the INCBINs should be left alone, in a safe location of the disassembly. You always want ALL your resources to be included in your ROM. You should look at the code and figure out how it works, even if you know nothing about assembly language. Let's try this with simple words. Assuming you're using the Hivebrain 2006 disassembly, I'd say that the "ObjPosLoad" subroutine might be of your interest. The intuitive name suggests that it Loads the Position of the Objects. Fair enough. At "OPL_Main" you can see it does some operation which involves $FFFFFE10 (which is the RAM address for the level number), and there is an "ObjPos_Index" which sounds promising, even if you don't know what it is and how it's being used. Now, the easiest (but not necessarily the most optimal) way to do what you want to do is to take the whole thing, from "ObjPos_Index:" to the line before the useless "padding4", and duplicate all of it. Of course you'll need to alter the labels, so it can become "ObjPos2_Index", followed by "ObjPos2_XXZn" for the various zones. The INCBIN'd files should be renamed, too. Follow any naming convention which makes the most sense to you. Once this is done, you have two separate indexes of object positions, but the second one will never be used yet. So let's go back to the code above. Wherever you see a "lea (ObjPos_Index).l,a0" (which is used to "Load the Effective Address" of some stuff), you have to add the trickery suggested by Hitaxas. Or something like this (assuming your character flag is 2 when playing as Knuckles; it should be 3 if you do it like S3&K): Code (Text): cmpi.b #$2, ($FFFFsomething).w beq.s I_Am_Knuckles lea (ObjPos_Index).l,a0 bra.s CommonCode I_Am_Knuckles: lea (ObjPos2_Index).l,a0 CommonCode: Do this for all the instances of the lea command. Of course you'll need multiple label names (e.g. I_Am_Knuckles1) the other times.
Thanks for the help! Once I knew what labels to mess with, and what line of code I had to mess with, I was able to do it :3 Edit: Um... this crashes the game when you play through scrap brain and labyrinth zone, as well as right before the Star Light Zone boss. Can someone please explain that to me?
Not sure about the SLZ boss issue, but notice how you mentioned the two zones which have some additional files in the ObjPos_Index, make sure you took that into account.
I changed the code for SBZ's spinning platforms to always reference the first index, but it still crashes. Also, I can't track down the object that causes labyrinth's crash. I'm really desperate to find out how to fix the SLZ boss, I might be able to work around the other crashes.
Is there any way to use bincludes in a way that won't start a new segment in the AS assembler? I've been experimenting with Z80 code that's kosinski-compressed during the build process, and it seems that two bincludes together mess with the segments: p2bin starts throwing 'The compressed Z80 code must all be in one segment' errors at me. It seems that s2.sounddriver.asm and Z80 Sound Driver.asm don't use bincludes in their Z80 code segment(s), so I can't use them for reference as I've done up to this point. I've looked around the AS Manual for anything on segments, but what I did find didn't help. Nothing in the BINCLUDE and INCLUDE areas seem to say anything on their relation to segments. I should point out that in the code I'm using, two bincludes cause problems, but in s2.sounddriver.asm, only one is needed. I could just 'db' the data, but I want it to be accessible as an external file.
I am trying to follow the guide on the wiki about porting the S3K object manager to Sonic 2. Now the guide is based on an old svn version and I of course only ever use the 2007 disassembly. I am stuck slightly on part 4, the area of the guide that has you edit the way objects handle deleting themselves. I can do this for most objects, but the bridge object from EHZ and HPZ (Obj11) is structured a little differently, and trying to use a similar method on that object causes strange issues. The question is, how should I edit this object so that it works properly? Apologies, The object giving me troubles is the Monitor object, obj26 (including a bug where the bridge deletes itself after a monitor is hit.) I am not sure why this is happening... Edit: My issue now, after working out a few things, is that the monitor respawns, if you run away from the object after breaking it, and move so it's out of the camera, then go back to it... it reappears, unbroken.
I remember that... You know that object index code you have to play with. 7,2(aN) and 0,2(aN)? Remove the 7,2(aN) in the object. IIRC any objects with both of them need the 7,2 removing. Look at S3K's monitor object for reference. Yes, the guide really doesn't help. EDIT: Snippet from S3K's monitor object: Code (ASM): loc_1D57E: addq.b #2,5(a0) move.b #$F,$1E(a0) move.b #$F,$1F(a0) move.l #Map_Monitor,$C(a0) move.w #$4C4,$A(a0) ori.b #4,4(a0) move.w #$180,8(a0) move.b #$E,7(a0) move.b #$10,6(a0) move.w respawn_addr(a0),d0 beq.s loc_1D5D0 movea.w d0,a2 btst #0,(a2) beq.s loc_1D5D0 move.b #$B,$22(a0) move.l #Sprite_OnScreen_Test,(a0) rts Note that I've never experienced your other problems, so you may have errors elsewhere.
But the question is... If you only use the 2007 disasm, then how do you have the Clone Driver v2 in your hack?
I'll have to take a closer look at s3k's objects, thanks for the help Clownacy. As for Xeta's question, It is rather simple. Follow the installation guide from the topic. Then you have to copy and paste the ID macro from the Git version, and same for the PSG_input constant. Also you need the constants that are part of the guide, put them in the beginning of s1.sounddriver.constants.asm. then change the idstart lines for music, sounds and special sounds to $81, $A0 and $F2 respectively. However, You won't be able to make use of the additional $80 sound ID slot, unless you can find a work around. That should be everything.
I was wondering something. I have been following a few of the How-To guides and noticed that the How-To guide for fixing ring timers does not include how to fix the issue using the Hivebrain dissaembly for Sonic 1. I was able to figure it out and fix the ring timers in the Hivebrain dissaembly but wanted to know if it would be worth it (and if so where) to post this for other users that might be using the Hivebrain dissasembly. This way they can easily be able to fix the ring timers in Sonic 1.
You know, this is actually very interesting. I originally had a post written up about how users of the Hivebrain disasm shouldn't be inexperienced enough to port from the later disasms. I talked about how the only people that should be using Hivebrain are the people that have used it since it was the newest thing, and that all newcomers should use the Community disasm, since it's easier to read with its many equates and better commenting. I rambled about how I plan to update the entire SCHG How-to set to support the latest disasm, when something occurred to me. I remembered way back to when I was new to hacking. I looked through the How-to list and knew that they were intended for Hivebrain. I wanted to get into hacking, but before I could write my own code, I needed to see how others did it. So, I used Hivebrain, because copy-and-pasting the code would give me errors. Yes, there was minimal effort on my part; I made no attempt to figure out what changes the guides made to the code, and just copied over the blocks of changed code they provided. Now, I thought that was just my behaviour, but the fact that others seem to lack the ability to port code between disasms has lead me to believe others (many others) do it too. Eventually, I found guides that were designed for later disasms, and because of my bad habit, I couldn't follow them. It was an annoyance, but looking back at it, it was a blessing in disguise: I wanted to be able to follow those guides, but that would require working on my understanding of how ASM hacking really worked. Months later, I reached that goal: I was able to pick apart the changes the guides made me do, and 'took off the training wheels' as it were, by switching to the Hg disasm. With my new knowledge, I could port the Hivebrain guides I'd been using all of this time to Hg, and vice versa. My point is that the barrier imposed by mismatched guides made me drive myself to learn. Were it not for that, I might still be a copy-paste noob today.
I prefer my information current. I don't like using any weird tricks to learn anything. I'd prefer a guide that explained what it was doing than a guide that amounted to "put this block of code here", no matter the disassembly. The fact that many of the guides were for older disassemblies was just another annoyance to me.
You know, it's kind of the same for me, too. The more and more you follow the guide, the more you actually look at it and see where they're going. I still think that the guides should be updated to also support the current disasms. I like the privileges that nowaday's disasms provide, like the Clone Driver v2, SonED2 projects, and SonLVL INIs, but there are times when comparing code can be difficult. Usually it shouldn't be too terribly hard if it's not too complicated a guide and you have basic coding knowledge, but since parts of the disassemblies have changed, it can be harder for other guides.
Not a question... but I wanted to make note of something... Some of you green badge toting dudes will know this, I'm doing this more for the less experienced, as I wasn't sure of it until now. Anyone who has played Sonic 2 Recreation... or hacked Sonic 3, MAY know many of the reasons WHY Sonic 3K is overall much faster and more efficient than its predecessors. There's the priority manager, object manager, rings manager (which isn't even in existence in Sonic 1), Build_sprites, etc. There is another one in particular that I've just started looking into, for porting to my Sonic 1 hack... TouchResponse. This is the subroutine that handles Sonic's collision with various objects. I also noticed that this is not found here. I think we can now add it. OBJECT COLLISION Sonic 1: ReactToItem: Sonic 2: TouchResponse: Sonic 3K: Test_Sprite_Collisions: SPRITE BUILDING Sonic 1 and 2: BuildSprites: Sonic 3: Render_Sprites: Here you go everyone, I hope this helps at least one person... NOTE that with S2 and S3, the sub starts with a jump to Ring Collision, which makes use of the Rings Manager, which is nonexistent in Sonic 1... so unless you port that over too, you won't need this. In the near future I'll be looking more into these subroutines for S3K and adding the equivalents to the noted wiki page... EDIT - Added BuildSprites equivalent. I'm thinking of moving this over to my Sonic 3 hacking thread that I started a while back.
Just a quick question. Does adding chunks to a zone (like adding cunks to GHZ through SonLvl) overwrite anything? Or does it just make for bigger files? Oh and another random one, how would I go about having emeralds as in-stage collectibles? More specifically, do I need a new object or can I just adapt the existing one?
The limit for 256x256 chunks decompressed to RAM (S1's default behavior) is $52; the limit for 256x256 chunks stored and read uncompressed from the ROM, and any kind of 128x128 chunks is $FF.
I'd think you can edit an existing one to do this, you just gotta do a couple things: 1. If we are talking Sonic 1, the emerlad in the Special stage is NOT an object, so you'd have to create it. I'd suggest using the unused switch object. IDK if this holds true in S2 or S3... I'm guessing it does. 2. Have the emerald art in VRAM for use. 3. Add object collision code for the emerald that will add to your emerald count, as none exists on the count that it's not a real object in the Special Stage.
That makes sense. Another chunk related question, say I were to add custom chunks to place in the levels in addition to those already placeable/selectable, would I need to find space for these additional chunks?
