[BetaTwizzler]

Does anyone know of a way to to port the no path-swapper system from Sonic 1 to Sonic 2, is it even possible? I just find them really annoying to keep placing on my loops and hills and such :p

[Thorn]

^ What makes Sonic 1 different than Sonic 2 in that respect is that Sonic 1 uses a single collision path instead of two (path swappers move you between paths and change whether Sonic's sprite is behind or in front of high-priority level art). To remove it from hills, all you'd need to do in SonED2 is set every level chunk except loop chunks to have the same collision in both paths. You can either choose to use a three-swapper setup (entry, midpoint, exit) on each loop that'll be the same in each level and thus less of a pain, or you can finagle some ASM to recognize when you're near a loop chunk and set the entrance and exit chunks based on direction of travel (this is what Sonic 1 does).

Do understand that you're sacrificing a lot of power over your designs this way. Cross paths, while not impossible, are much more difficult with only one collision path, and zones like Chemical Plant are dependent on them. I highly suggest you grab these and replace your SonED2 object definitions for Sonic 2 with them. These will give you visuals for path swappers, showing you 0/1 collision path changes and low/high sprite art changes. (Note that while not shown, a mirrored pathswapper will nullify path changes but keep art changes). With this, you can see how each swapper works without having to check each one's properties individually. Follow paths with your finger, and use Q/W/E/Y/U to toggle paths and art settings.

[BetaTwizzler]

I highly suggest you grab these and replace your SonED2 object definitions for Sonic 2 with them. These will give you visuals for path swappers, showing you 0/1 collision path changes and low/high sprite art changes. (Note that while not shown, a mirrored pathswapper will nullify path changes but keep art changes). With this, you can see how each swapper works without having to check each one's properties individually. Follow paths with your finger, and use Q/W/E/Y/U to toggle paths and art settings.

Awesome, Thorn, thanks! These made working with swappers a lot less annoying for me, no more trial and error and building and deleting to see what works, lol.

[CAE Jones]

I'm trying to write a program that monitors save states and can give verbal descriptions of things like level layouts.
The scripting language I'm using is decidedly not the best for this task, mostly because it loads binary files as strings. It can convert them into hex, which basically doubles the size. So I'm not confident in my ability to find my way around the data.
I'm working with Sonic 3 & Knuckles (Yeah, pretty sure I should have started with Sonic 1 or 2... it was the easiest to get to when I started. No sense in changing games after I've gotten into it, right?)
I've been able to track down basic variables all fine and well. I'm a little worried that the address I got for the master level trigger appears to be a byte off from where the guides say it should be, but the number of rings collected is right (I blame the method I'm using for looking at the data).

Where I'm hitting problems is level layout things. I've read the Nemesis guide and the more updated SCHG guide on this several times. I've found what could be the layout header, but I can't make sense of what comes after that.
I don't need anything related to the appearance of things—tracking downs objects, identifying them, and giving their position is the most of it.
Pretty sure this has been done, since level editors exist. Those don't help me much, though.

It looks like one of three things, here. 1, I'm completely lost with how I'm doing this (is layout data even saved in a save state?); 2, the method I'm using to examine the data is screwing with the offsets; 3, I'm just really confused by how level layouts are handled (pointers and different-sized block-mappings all over the place are hard to keep straight with my lack of experience).

I'm kinda hoping it's 3, as in that case I could probably just show my numbers and see if anyone can tell me what I'm doing wrong.

Right now, I'm looking for layout header data at $8000 and $A478. To find where my script put them, I multiply by 2 and convert to decimal. So the indeces my program checks internally are 65536 and 84208. If it helps, the program looks for rings internally at 148786, and it looks like the MLT is at 144624-144625.
(I'm rather confused by how well this scripting language I'm using works with hex. Hopefully it'll let me enter hexadecimal values so I don't have to convert all the time.)

... So... any idea what I'm doing wrong? :-/

[FraGag]

Depending on what you're referring to with "level layout," the data you need may or may not be in RAM. A level is comprised of a chunk layout, an object layout and, starting with Sonic 2, a ring layout (some levels have additional special layouts, like Casino Night in Sonic 2 for some bumpers). Chunks are 128x128 (Sonic 2 and later) or 256x256 (Sonic 1 only) pixels structures that define the main layout of the level and are strictly aligned in a grid. Objects can be placed with pixel precision and can do a variety of things and have a multitude of sizes and appearances (within the Mega Drive's limits). Chunks are composed of 16x16 blocks and contain collision information. The chunk layout (and the blocks that compose them) are stored compressed in the ROM, so the game has to decompress them in RAM to use them, which means that it's available in a save state. However, the object layout is not compressed, so it's read directly from ROM. The object manager uses pointers to track the "region" of the object layout that is currently loaded. If you want the whole object layout at once, you're better off reading it from the ROM.

[CAE Jones]

I don't think I understand quite how chunks work (or where they are when decompressed into ram).

I've been working with the object status table, and am not sure how to identify objects (other than player1 and player2). It sounds like there's a pointer somewhere to entries in those lists (sonic3/knuckles), but is this associated with the object's status in ram? This looks like the easiest way to identify an object.

I notice a lot of objects with dimentions of 0 or 1. I don't know what these could be (I'm working with AIZ at the moment).

[Hitaxas]

In Sonic 2, what routine makes it so that the screen shakes when the bosses appear in levels such as ARZ or MCZ?

[Selbi]

In Sonic 2, what routine makes it so that the screen shakes when the bosses appear in levels such as ARZ or MCZ?

For the Hill Top Zone, it's at loc_CA92:

Syntax Highlighted Code: ASM

		move.w	(Timer_frames).w,d0
		andi.w	#$3F,d0
		lea	SwScrl_RippleData(pc),a1
		lea	(a1,d0.w),a1
		moveq	#0,d0
		move.b	(a1)+,d0
		add.w	d0,(Vscroll_Factor).w
		add.w	d0,($FFFFF618).w
		add.w	d0,($FFFFEEF4).w
		move.b	(a1)+,d2
		add.w	d2,($FFFFEEF0).w

I haven't checked it, but I'm pretty sure they are identically for ARZ and MCZ.

[Hitaxas]

Might as well echo this in this topic since the original topic got trashed/locked, and I would like to know if anybody has an answer.



Would anybody be able to explain how/why this happens in the game? Would be awesome to fix.

This post has been edited by Hitaxas: 11 June 2011 - 09:19 PM

[Squidgy]

I don't know if this question is too complicated or specific for this topic, but I'm having some major trouble hacking Sonic 3 and Knuckles. I'm using Chimpo's guide and jamn2050's disassembly. I'm using SonMapEd, trying to change Sonic. I'm trying to learn by replacing Sonic with Mighty.
The first problem I had was when I had to make new mappings. I went and did what Chimpo's guide explained, and when I imported my sprite over it, it actually covered the tiles, and they stayed there. So I had Mighty sitting on this background made of random colors. I learned I could fix this by using edit>tiles>remove pixels of selected tiles, then importing my sprite. I followed the guide, and everything seemed to go well. I ended up with this:
Picture.
(Excuse the blurriness, currently searching for a better image host)
So I go to the disassembly, and I use the buildsk.exe. But then I get this error:
Picture.
What the heck is going on? I go to SonMapEd again and find an answer... sort of.
Picture.
What am I doing wrong? I'm very confused right now. I'm not an experienced hacker, obviously, so any help would be appreciated.

And if this question is complicated enough to warrant its own topic, let me know. I'm trying to learn and I need some help.

EDIT: After messing with SonMapEd a bit, I've found yet another error that popped up when I tried to assemble it.
Picture

This post has been edited by Squidgy: 13 June 2011 - 10:34 AM

[FraGag]

The first error (too many operands) happens because AS (the assembler used for the S&K disassembly) doesn't accept more than 20 operands (there are 38 here). You could try splitting the line into 2 dc.b directives after 20 operands, but because this file is generated by SonMapEd, you'll have to fix the file every time you edit it in SonMapEd.

The second error (symbol undefined) happens because SonMapEd overwrites General/Sprites/Map/Sonic pattern load cues.asm and General/Sprites/Map/Map - Sonic.asm and discards the labels that were originally in the file. Moreover, it didn't even load all the PLCs and all the mappings, so when you saved them, it completely discarded the Super Sonic DPLCs and mappings. The issue here is that there are 2 sets of DPLCs and mappings together and some of them share some data, but SonMapEd doesn't support working with that. If you want to continue using SonMapEd, you'll have to make 2 DPLC files and 2 mapping files, one for Sonic and one for Super Sonic.

[Squidgy]

I don't want to sound totally noobish in asking, but would you mind explaining exactly what I'm supposed to do? I think I understand the second one for the most part, not absolutely sure, but I don't really get what I'm supposed to do for the first error.

[nineko]

I'll try to repeat with simpler words what FraGag said.
You can't put too many numbers after a dc.b
According to your screenshot, right now in your "Sonic pattern load cues.asm" file you have this line:
dc.b 0, $12, 0, $2F, 0, ... and many other numbers separated by commas
You can't have more than 20 of those numbers on each of those lines that start with a dc.b
So you have to split them up by creating another line which starts with dc.b
To do this, you have to open the "Sonic pattern load cues.asm" file in notepad or any other text editor
And you have to turn this:
dc.b 1, 2, 3, 4, 5, 6, 7, 8
into this:
dc.b 1, 2, 3, 4
dc.b 5, 6, 7, 8
(of course this is just an example, you don't need to split them up if there are less than 20 numbers)

Since it turns out that the "Sonic pattern load cues.asm" file is written automatically by SonMapEd, you will probably need to perform this operation every time you'll edit said file in SonMapEd (I can't tell since I never used SonMapEd in my life so I'll go by FraGag's words).

I hope this is clear.

btw:

Excuse the blurriness, currently searching for a better image host

http://imageshack.us

This post has been edited by nineko: 28 June 2011 - 07:21 PM

[Squidgy]

Alright, thanks. That cleared it up. However, I still need help with the second error. I don't know how I'm supposed to "create" 2 DPLC's and 2 mapping files.

[Aerosol]

Hey guys. I'm (still) trying to put Sonic's Sonic 3 sprites and palette into Sonic 2.

I imported Sonic's Sonic 3 tiles, mappings etc into SonMapEd from the ROM, and did the same for his Sonic 2 stuff in another SonMapEd window. I've reordered most of the Sonic 3 sprites, but in Sonic 2, the Super Sonic tiles are included with the rest of Sonic's tiles, whereas in Sonic 3 they're seperate location. What's the best way to get the Super Sonic sprites with the rest of the Sonic 3 sprites?

And on top of that, how can I get them to display right in SonMapEd? no matter which pallete, mappings, and loading cues I use, the Super Sonic sprites look garbled.