Basic Questions and Answers Thread

Ah yes, objects in S1 other than Sonic have flipping flags in the animation data. You can either port the animation routine over or hardcode the flipping into the object. Well, I guess you could also just make a flipped version of the frame and use that.

 

I like to reference the SCHG pages on Sonic Retro a lot, for obvious reasons. That said, there's a handful of odd things written there. Among them is this little note on Y-wrapped levels in Sonic 2s' ram page:

I always thought this was a really odd thing to say; LZ act 3 was Y-wrapped in Sonic 1, why would Sonic 2 break that? I blindly took this little note as gospel, regardless, since I didn't know any better, and didn't feel the need to Y-wrap a water level anyways. Recently, though, I decided to copy LZs' level layouts into S2, with the water routines and level sizes. Despite the above quote, LZ 3 works exactly as expected with no edits, and quickly Y-wrapping HPZ works just fine too (although the water does look a little odd during the transition at it's default settings).

Does anyone have any idea why that note is there and if it holds any meaning at all? I'm starting to feel kind of silly, having trusted it for nearly 2 years

 

Why yes, I do know. The issue comes from when you actually Y-wrap. Your Y-position will be kept roughly between $FF00 and $720. But what about when you go outside of it? Simply, your y-position is just ANDED. This also means, camera position must follow this logic to follow the player, and since the water line is calculated from the camera position, if you fall too low on the level, the water disappears. If you go too high, water suddenly appears. LZ3 plays around this limitation by stopping the water in the incline section where you are going up to the boss. It has good time to first remove the water at appropriate place, and then re-enable it. I think the level also removes the wrapping position when the water reappears, making sure you do not try to go back down. I don't remember fully anymore, its long since I took a look at it. So yes, you CAN have water at y-wrapped level, but you must be incredibly careful to not let the player wrap while water is present.

 

Yeah, I did the same thing in Knuckles' Emerald Hunt's version of Hidden Palace Zone, once you reach the area where you climb the wall, I enable Y wrapping and disable water.

 

I've stumbled into an error that I simply can't find out how to debug, despite knowing pretty much what the problem is

The issue is that on Regen, the game jumps into code at a bad offset and crashes because everything is misaligned. However, everything works fine on Kega Fusion. This led me to assume that it's due to an odd offset being used, as Regen (and hardware, too) are much pickier then Kega about odd address values. Great, so I should an even or two somewhere... But where?

How do I tell what the game was doing immediately before jumping into garbage code? It'd be a hell of a lot easier to fix if I knew that. The Regen Debugger lets me see all the values in ram, but since the crash happens after the bad jump occurs, all I can see is where the code it crashed on is, which isn't very helpful.

 

Usually when this type of error is triggered, Sonic games tend to display the error, as well as the offset where the error triggered, you should see "ADDRESS ERROR", followed by the address, that address "should" be where you'll need an "even" to be placed roughly, but this is still quite troublesome to tackle.

There are certain error handlers written by a few members around, which are far more advanced and clear on the error, I believe flamewing has one, as does vladikcomper. I couldn't tell you which one is better, since I've never used them, I'm also having trouble finding flamewing's right now, so I'll just link vladik's for now:

http://sonicresearch.org/community/...rror-handler-for-your-hacks-and-homebrew.4442

 

flamewing's error handler

 

I actually have Flamewings error handler, but Regen won't let it appear for some reason; it just pulls up the Regen debugger and locks up the game... I guess I'll have to see if the error handler works on my Nomad then.

EDIT: My nomad was being finicky, so I decided to test in in Exodus... It just works there
And on hardware, it just freezes, even though I have the debugger installed. It seems the debugger won't come up for some reason or another...

 

The only thing I can suggest, is placing the following:

Code:

		move	#$2700,sr
		bra.w	*

Near roughly where you believe it to be crashing. For example, if the crashing takes place at the beginning of a level's title card, then you'll place this somewhere in the level's initialisation loop.

When the 68k locks, you can check in the debugger, and if it is stuck in that "bra.w" loop, you'll know the 68k has successfully reached that point, thus, the crash is likely to occur later on. So you move the instructions above, further down the routine, and check again. If at some point it crashes in the way that you suggest (by that I mean, it doesn't lock by getting stuck in that "bra.w" loop), it is likely to occur before the instructions.

What you'll be effectively doing, is narrowing down where the problem is, until it points you to the area of the problem.

This will not be practical for crashes that occur in loops, those that are able to run endlessly without a problem before the crash randomly occurs. but it can be useful for instances where nothing standard can help. For better clarity, you could after the sr setting, set VDP to CRAM write mode, and change the palette (if not all of it, then the backdrop colour) to a specific colour, so you can see if it traps in your deliberate branch, or not (for say on hardware).

I might also suggest the Z80 too, if the Z80 is accessing the VDP area, this can cause a lock of the machine which isn't of fault of the 68k, but I doubt this would be your problem.

Sorry I can't give much more help than that, I will ask though, where during the game itself does the crash actually occur? This might help us think of something not thought of before.

 

I realized I should've checked the sonic1.asm thoroughly, and I've figured it out
Tiles are Nemesis
I looked to Title_LoadText and seen

Code:

lea (Blk16_GHZ).l,a0 ; load GHZ 16x16 mappings
  move.w #0,d0
  bsr.w EniDec <---- Enigma
  lea (Blk256_GHZ).l,a0 ; load GHZ 256x256 mappings
  lea ($FF0000).l,a1
  bsr.w KosDec <---- Kosinski
  

Does the collision need to be compressed in some kind of way???
EDIT: the layout too? I know in Sonic 2 it's Kosinski

 

Spoiler: Original Post

I've added a ludicrous amount of Zones in Sonic 2 ($22 in total are accessible in game at the time of this writing, and more to come in the future). One specific one, $1F, causes the game to jump to invalid instructions right about where you'd expect the title card to go away (before any level art is actually displayed). I know I'm adding the zones correctly; $11 - $1D have never had any problems, and $20-$22 don't show any symptoms either. All the data for the zone (Collision Primary/Secondary, artwork, blocks and chunks) is valid and aligned with the other zones data as well; palette cycles, level events, animated art, etc. all point to EHZs' code (or assets in the case of animation scripts and APMs), which I haven't touched. Even it's PLCs are currently pointing towards EHZs' data. The only notable changes are that it has new blocks, chunks and artwork (all of which are identical to EHZ), a custom pallete (I would be genuinely impressed if that could cause a crash ), modified object positions (a few enemies were removed... and it still works on Fusion and Exodus, so an invalid object is unlikely), and a separate layout which is again a copy of EHZs' layout.

Perhaps the strangest part about this issue, however, is that it also used to effect $1E as well. However, after adding more data to $1E and/or $1F (defining separate art, layouts etc.) and adjusting some code, the issue has completely resolved itself there. My current best theory as to what's happening is that it's related to these levels being at the very end of my current zone list, as $20-$22 are all essentially copies of CPZ, with all their pointers taking CPZs' data instead of custom data. Thus, $1E and later $1F were my last truly defined separate zone in zone ID order. Then again, that's just a theory, if I knew precisely what was happening I would have fixed it by now. It also doesn't explain why $1D, $1C, and my other previous "last" zones didn't similarly crash.

That's a wonderful idea! I've just woken up, though, so I'm not really in the headspace to go poking around my code right now. I'll edit this post later with my results.



EDIT: I've pinpointed where the crash occurs! It happens a ways under Level_FromCheckpoint (In the Sonic 2 GitHub disassembly). This code block is precisely where it happens:

Code:

;crash occurs AFTER here!
    move.b    1(a1),(Demo_press_counter).w
    tst.b    (Current_Zone).w    ; emerald_hill_zone
    bne.s    +
    lea    (Demo_EHZ_Tails).l,a1
    move.b    1(a1),(Demo_press_counter_2P).w

+
;crash occurs BEFORE here!

I have no idea why, though. I've never messed around with the demos before, and they work as intended on the title screen. I'm not even making a demo for this zone, it crashes during a non-demo level load. Commenting out the above code doesn't even change very much, other then making tails always run his EHZ 2P demo in every demo. That does fix the crash though, so I'll do it temporarily just so I can test on Regen again.

EDIT2: Fixed the crash. Apparently, not extending the demo list caused this. Not sure why none of the other zones crashed though

 

Based on that post above, the code probably tried to read from memory address between $800000 and $E00000. From my experience, the console doesn't really deal with memory accesses here well, aside from few bits around these regions, especially with Mega CD or 32x attached. Regen usually just brings up the debugger and some emulators just ignore it (by returning FF or 00).

 

How does volume control in Clownacy's modified MegaPCM work? Simply adding unsigned 8-bit wav files and using them as they were resulted in them playing very quietly. Because of this, I heavily boost volume of the sound file itself externally to make them audible, which obviously resulted in a massive drop in quality (this is likely why nearly all of my custom samples in Robotnik Returns 2 sound like shit). I've recently been putting effort into improving the audio quality of my samples, but they're still nearly inaudible without arbitrarily raising their volume externally and thus making them sound like garbage.

Clownacy has mentioned that the version of MegaPCM bundled with the Clone Driver v2 has volume control, but I've been unable to find documentation on it. However, I did find the label "MegaPCM_VolumeTbls", which seems to be related to this feature. I've yet to figure out how to utilize it effectively, though; adding extra values at the end of the table just seems to make the samples even quieter, to the point of being almost completely silent.

EDIT: On further investigation, that almost silences ALL DAC SAMPLES. I don't know what I'm doing

 

If you want the volume to not be quiet, you are gonna have quality loss. Since DAC is only 8 bits and the way the DAC is handled, your best bet is to raise the volume conservatively. Just enough for it to ve audible but not too loud. Samples with more consistent volume (less very high and very low volumes and with less variation) are gonna work better. Or, samples which already sound louder. Simply, its not an easy issue to solve but if you are clever enough it is solvable.

 

http://forums.sonicretro.org/index.php?showtopic=32801&view=findpost&p=845731

https://github.com/Clownacy/Sonic-2...-a-DAC-sample-during-gameplay-(with-Mega-PCM)

https://github.com/Clownacy/Sonic-2...b/Sonic 2 Clone Driver v2 - Functions.asm#L69

https://github.com/Clownacy/Sonic-2...2c5337efb13b546440daeb/MegaPCM - Z80.asm#L146

There were a bunch of places you could have looked.

 

I know, maybe somebody already asked that question but how do animations in Sonic 1 work? I found something that I think is a number of frame (highlighted on screenshot) but the rest is a mystery for me. I tried to look on Sonic Retro's SCHG but I didn't found what I searched for.

 

The animation format is the same in all three games. The first byte is the duration of each frame of the animation (some values are reserved for walking/rolling), then a list of frame IDs, then a value in the $Fx range to indicate how the animation ends (back to start, jump back to a specific frame, change animation, etc). In Sonic 1 specifically, objects other than Sonic can also have X and Y flip flags in the frame IDs.

There's an animation editor included in the SonLVL toolset, if you're looking for a more visual representation.

 

How can I record demos for the title screen? I haven't been able to find anything on it. It doesn't exactly help that searching for answers brings up a bunch of rom hack demos The closest I've gotten is this tool called Sonic Tweaker, which is an obsolete ROM editing program.

I've found the unused routine for recording demos in Sonic 2, but I'm not sure how it's supposed to work; I'm not completely sure what everything in it does, but it appears to be trying to write to ROM, which obviously shouldn't do anything useful.

I can see that the demo scripts are editable in ASM format in the Sonic 2 GitHub disassembly, but obviously, that's not exactly the best way to make them.

 

There are various ways, this is one. You record a GMV using Gens Rerecording, and then you convert it. Please note that I never used it, but other people seemingly achieved good results with it.

 

That particular tool happens to have a dead link, so I can't use it... I appreciate the thought though

EDIT: The link works now!