yes sonic 2 to sonic 1 needs a LOT of code change, so obviously sonic 3 will have even more change compare labels between sonic 3 and sonic 1 and replace them as necessary
Sorry i was unclear- I meant to say, why does .decideScrollType uses sonic inertia as the determining value if it is to call .doScroll _fast ? Does sonics inertia determine how far sonic y will move next frame and that is why is uses the inertia as the determining factor? What's the inertia got to do with whether to cap at 6 or 16 pixels
It just allows the camera to go faster when Sonic is moving fast on the ground. Slight camera lag can still happen even if you're slightly above normal top speed ($600), but under $800 due to the cap being 6. Why they decided on that, I could not tell you.
Recently, as a personal project I've been playing through all the old 16 bit and 8 bit Sonics with an additional completion criteria, trying to achieve the 'special bonus' (which only actually exists in 8 bit Sonic 1) in all the different games. This amounts to basically not dying, entering and finishing all bonus stages and most interestingly, trying to find every 1-up monitor in the game. For the 16bit games, I can easily use SonLVL to make sure I'm not missing any, but I'm a bit stuck with the 8 bit games. Focusing on Sonic 2 at the moment. Does AspectEdit have the ability to at least view items, or can the disassembly be inspected to work it out? Just by playing the game, I make it 31 life monitors in total (+the continue monitor in Crystal Egg), and the game isn't that big so that's probably all of them, but I'd love to know for sure! Same goes for Chaos and Triple Trouble, but one problem at a time! As an aside, I'd love a hack which basically adds a 'Doom' style count of items, badniks and 'secrets' (you'd have to manually define which areas count as a secret, but that would be fun to do as well) to the classics. Would be a nice extra challenge for veteran players.
I don't think we've ever had Sonic 2 maps with objects (not even smspower has them), but I *think* I collected all the 1-up monitors in my playthrough, you might try comparing yours to mine.
Thanks @nineko I'll check it out. Also as I see your run is GG and mine is MS, a chance to spot if there are any 1-up item differences between the two!
Answering my own question with a little read of the hacking guide, with the binary in a hex editor, I can go to the sprite layout address, and look for the ten byte sequences where the first byte is a monitor and the seventh byte is type 03 for extra life. A bit fiddly but at least I'll know how many should be in each act! EDIT - I have now done this for all non boss acts and I didn't miss any, hooray!
So for Sonic Chaos, luckily hivebrain posted in an old thread where the first offset starts for the object positions in Chaos. It doesn't look like anyone has gone to the trouble of identifying the individual zone offsets and object types yet, so I've got cracking (at least for the monitors). The objects follow the same 9 byte pattern as the Sonic 2 monitors, so I can now definitively say that THZ1 contains 2 invincibility monitors (subtype 0x06), 2 rocket shoes (subtype 0x04) and 1 extra life (subtype 0x02). Interestingly, ring monitors seem to be their own thing and aren't using byte 0x10 to identify themselves like all the others.
Ring monitors replace the Rocket Shoes monitors when you play as Tails, which could be the reason why the ring monitor subtype doesn't follow the same rules that the other monitors do. I do have all the object layouts split up in my disassembly, though they're split up as binary files. I'm currently in the process of adding them to an easy to read/hack assembly file as we speak. (Honestly it's been quite a long time since I even touched my disassembly, well until now. )
Hello. This is my first question regarding ROM hacking (I've never made one before, either), so I apologize if I sound a bit stupid. Flex 2 only references Sonic 3 & Knuckles as an option (does that mean making ROM hacks of Sonic 3/Sonic & Knuckles is impossible with the program? What does Sonic 2 Special mean?! @_@) and the only tutorial for the program implied that I should get a disassembly. It would be nice if there were more tutorials for using the program, but I'm certainly not gonna ask for one. So, I went to the Disassemblies page on this site and found one. I assume it's only possible to make a ROM hack by doing so. I noticed that the README.txt file references "buildS3Complete.bat". Does the Sonic & Knuckles Disassembly reference Sonic 3 Complete (the ROM hack), or Sonic 3 & Knuckles? What defines "complete"? Wouldn't the standalone game be considered just that? I'm probably misunderstanding something. I might be asking quite a few questions for a while, so please be patient with me.
sonic 2's special stages use a different DPLC format than the rest of the game the build scripts set the Sonic_3_Complete variable as necessary Sonic 3 Complete in terms of the disassembly is a bit of a misnomer, as the gameplay is exactly the same and the only thing different is that the redundancies and padding are removed--it's like a "compressed" version of S3K if you will, but otherwise it's exactly the same. it's for you to transition to if you don't have any more room to fit stuff into afaik afaik S3 and S&K use the same format as S3K
I mean, it adds Sonic 3's data into Sonic & Knuckles, technically making it the "complete" Sonic 3 experience. That's really all that flag does, among some other misc. things like the DMA queue functions automatically handling boundary issues. And on that note... Even outside of the disassembly, S3K technically is just S&K, but with S3's data taken into account. There's an flag used to denote whether to run in S&K alone mode or S3K mode, depending on if a S3 cartridge is found. S&K was built off of S3's engine, so yes the formats are exactly the same. Wouldn't make sense to change the formats as that would break compatibility between the 2 parts of the game.
Well, there are a few differences between S3 and S&K, for example the special stage layouts are compressed in the latter. I know there are more differences even in some art formats, because I helped Varion convert some things several years ago, but I don't remember the details and I'm not at my computer right now.
Ah, I see. Thanks. I'm just doing a graphics hack for now, so I shouldn't have to worry about running out of room. I've come across a few other things that raise questions for me while learning the program (as much as I can). I'm trying to replace the sprites of Tails with my own sprites of a similar character, so this is a bit more difficult than your average recolor. It appears mapping isn't freely configurable, but I'm not entirely sure if this matters or not? I thought mapping determined how sprites deal with collision, but I could be wrong about that. Collision is necessary, so this is one of my main concerns. Importing individual sprites only places them inside the map tiles and doesn't just allow you to freely export them with options like "Reduce Mappings/Tiles". It appears importing a sprite sheet is the only way to achieve this, unless I'm doing something wrong. Another thing I'm unsure about is whether or not the position of sprites matter and how to go about it. There's several number values that go horizontally and vertically in "Mappings", but I haven't been able to find any information about this either.
if you mean like in the PNG file, try to line up the position of your sprites with the position of the sprites in the PNG. the original game's sprites are placed optimally so they fit the X and Y position (well, knuckles's up sprite is slightly positioned to the right by 1 pixel), but as you said, so you don't need to worry about knuckles
By .PNG, do you mean the Tails sprites that are part of the .bin files or the imported sprite sheet? If I'm understanding correctly (which is unlikely at the moment, haha), then I'll give it a try in a while. I thought of another question; Does Reduce Tiles give much of a benefit (space or optimization wise) compared to Reduce Mappings? It seems to increase the number of mapped tiles but at times can make the mapping look nicer.
I've finally learned the basic features of the program and managed to build a ROM out of the disassembly, although when I attempted to play it I noticed that the audio was choppy and a bit slow along with the game itself, and... a bit of a palette issue. Could it be I set the Game Format to the wrong setting, or another issue?? I thought "Sonic 3&K Sonic" was specifically for Sonic and not other player types like Tails and Knuckles, but I could once again be wrong about that. I tried looking through the documentation tab, but nothing was said regarding the Sonic 3&K formats. If I could know, that would be helpful. Knuckles seems perfectly fine since his palette and sprites load correctly, but Sonic and Tails' along with the zone card and life icon palettes get messed up. This would probably be fine if I was making a certain "Sonic Executable" ROM hack, but I'm certainly not going for that.
that maybe is the issue (i'm really stretching the maybe) but i'm not sure how it would: maybe your emulator was lagging? reduce tiles should remove duplicate tiles, and reduce mappings should make the mappings optimally
