[Neo]

ColinC10, on 19 September 2011 - 06:35 PM, said:

You obviously didn't make the right choice. The level is very easy when you pick the correct path and technique, and very difficult otherwise. </smugmode>

Is this even true? At least one of the crushers (the top one?) seemed impossible, and I'm not sure how you'd get through some of the spikes.

You should make a video of clearing all six choices like a pro. Without using the crusher exclusion bug.

[WouldYouKindly]

This hack is pretty damn impressive. I ended up ragequitting at Multiple Choice; you got really evil with some of the challenges .

I do have one complaint though. I have noticed some pretty annoying sound glitches occasionally (Fusion emulator, not sure if it happens with anything else). Occasionally when destroying a Badnik or if a platform crumbles, the sound effect gets distorted for a second or two. Nothing major, but annoying and somewhat ear-raping on occasion. Might be worth trying to fix.

EDIT: Guess I need to read the OP more thoroughly /facepalm.

This post has been edited by WouldYouKindly: 20 September 2011 - 11:48 AM

[ColinC10]

Neo, on 20 September 2011 - 04:05 AM, said:

At least one of the crushers (the top one?) seemed impossible, and I'm not sure how you'd get through some of the spikes.

I don't think this level's quite worked the way I intended it to, unfortunately. The idea was to have a choice of three routes for each of the two types of trap. They were meant to look equally difficult, however one of them had a technique that allowed the player to pass the trap easily, while the other two options were actually impossible. The challenge is therefore to use your knowledge of Sonic's physics and how he interacts with objects to pick the correct route, rather than a timing/skill test. After all, in a Multiple Choice exam, there is only one correct answer!

However, I obviously didn't test this thoroughly enough because I've seen videos of people passing the spike trap using both the top and the bottom routes, and doing it using a method that would be very difficult to repeat in a non-tool assisted run. In addition to this, I gave away the correct route for the second section by including the trap in the final level! Not very impressive, but I suppose one or two weak levels out of 40 isn't too bad.

The correct path and method for the crusher section has already been described earlier in the topic. If you find the spike section ridiculously difficult, then you might want to take another look at it with the above in mind. For those who still can't get this part, here's a hint:

Spoiler

I introduced the technique you need to use back in the second filesystem.

And if you're sick of this level, here's the full solution:

Spoiler

Spike trap: Take the bottom route, stand near to the pit, then spindash straight across to the other side while the ceiling spikes are down.
Explanation: With enough speed, Sonic can cross horizontal gaps of up to 8 blocks. The other two routes don't have any pit to spindash across.

Crusher trap: Take the middle route, stand under the first crusher and near to the second one, then jump forward as the first one comes down.
Explanation: Sonic can't be crushed while jumping, so with enough sideways momentum he slides safely out of the way. This doesn't work with the bottom route because the crusher forces him into a standing position as soon as it touches him, and the top route is blocked at all times.

[RGamer2009]

ColinC10, on 20 September 2011 - 01:48 PM, said:

And if you're sick of this level, here's the full solution:

Spoiler

Spike trap: Take the bottom route, stand near to the pit, then spindash straight across to the other side while the ceiling spikes are down.
Explanation: With enough speed, Sonic can cross horizontal gaps of up to 8 blocks. The other two routes don't have any pit to spindash across.

Crusher trap: Take the middle route, stand under the first crusher and near to the second one, then jump forward as the first one comes down.
Explanation: Sonic can't be crushed while jumping, so with enough sideways momentum he slides safely out of the way. This doesn't work with the bottom route because the crusher forces him into a standing position as soon as it touches him, and the top route is blocked at all times.

WOW, that was it? Really?

I took a completely different approach, same path:

Spoiler

I waited till the top and the bottom sets were about halfway to changing with bottom spikes up, then jumped in. If you timed it correctly, the spikes would change as you fell, and you would not get hurt. Then you walked over and jumped out as they changed again, leaping clear of the pit.

I'm going to have to try your technique though. That's very interesting indeed.

[GerbilSoft]

I haven't verified this in the ROM itself, but since this ROM uses 6 MB with flat addressing, you may want to verify that the emulator actually supports it before starting. This could be as simple as checking for a known 16-bit value at $5FFFFE (or 32-bit value at $5FFFFC). If that value doesn't match, then show an error message indicating that the system doesn't support 6 MB ROMs.

Gens/GS supports up to 6 MB with flat addressing (and up to 5 MB using SSF2 bankswitching). I haven't checked Kega, but obviously it has to support at least 6 MB since it works fine with this hack. :P

This post has been edited by GerbilSoft: 20 September 2011 - 09:07 PM

[Sik]

Wait what, 6MB with flat addressing? I don't think there's any game that actually supports that other than the UMK3 hack as far as I know. I wonder if this is what Snake meant with some game requiring 6MB to work fine... Some unlicensed game? Does anybody even know what game is it, because Snake told me he didn't remember what game needed it =/

[jasonchrist]

RGamer2009, on 20 September 2011 - 01:57 PM, said:

ColinC10, on 20 September 2011 - 01:48 PM, said:

And if you're sick of this level, here's the full solution:

Spoiler

Spike trap: Take the bottom route, stand near to the pit, then spindash straight across to the other side while the ceiling spikes are down.
Explanation: With enough speed, Sonic can cross horizontal gaps of up to 8 blocks. The other two routes don't have any pit to spindash across.

Crusher trap: Take the middle route, stand under the first crusher and near to the second one, then jump forward as the first one comes down.
Explanation: Sonic can't be crushed while jumping, so with enough sideways momentum he slides safely out of the way. This doesn't work with the bottom route because the crusher forces him into a standing position as soon as it touches him, and the top route is blocked at all times.

WOW, that was it? Really?

I took a completely different approach, same path:

Spoiler

I waited till the top and the bottom sets were about halfway to changing with bottom spikes up, then jumped in. If you timed it correctly, the spikes would change as you fell, and you would not get hurt. Then you walked over and jumped out as they changed again, leaping clear of the pit.

I'm going to have to try your technique though. That's very interesting indeed.

That's funny, because the top route for the spikes isn't actually impossible. In fact it's the route I take.

[Scarred Sun]

I would like to announce my disappointment that this is not some sort of recovered prototype for Sega VR.

That being said, this is pretty rad.

[ColinC10]

SadisticMystic, on 18 September 2011 - 06:02 PM, said:

It seems like the lives weren't entirely coded out: if you die a total of 255 times across all the levels, the music stops and you get sent to a glitched remnant of the SEGA screen, then everything just freezes. That's no good.

Oh, bollocks. For today's ASM test, can you spot the deliberate mistake in the code below?

addq.b	#1,(Update_HUD_lives).w	; update lives counter
;subq.b	#1,(Life_count).w	; subtract 1 from number of lives
bne.s	Obj01_ResetLevel	; if it's not a game over, branch

Spoiler

I've commented out the line that subtracts from your lives, but I've left the game over check in. This now applies to the line above instead. This line sets the flag that updates the HUD, but for some reason, Sega have used an add instead of a move. Without the HUD code this never gets reset, so it now acts as a count of the number of times you've died. After 255 comes 0, and 0 means Game Over - literally!

Ah well, it's not a disaster if this glitch does happen, because by resetting the game you'll get back to exactly where you left off, and there's no danger of your save file being corrupted because the Sonic 1 and 2 save system has been entirely replaced by the Sonic VR one (yes, this is a hack of a hack!)

GerbilSoft, on 20 September 2011 - 09:07 PM, said:

I haven't verified this in the ROM itself, but since this ROM uses 6 MB with flat addressing, you may want to verify that the emulator actually supports it before starting. This could be as simple as checking for a known 16-bit value at $5FFFFE (or 32-bit value at $5FFFFC). If that value doesn't match, then show an error message indicating that the system doesn't support 6 MB ROMs.

Gens/GS supports up to 6 MB with flat addressing (and up to 5 MB using SSF2 bankswitching). I haven't checked Kega, but obviously it has to support at least 6 MB since it works fine with this hack. :P

I'm not sure what you mean here. I use bankswitching to access everything from 4MB to 6MB, which works fine on both Fusion and Gens. Although, Gens seems to be a bit more picky about where you put things on the ROM: I had to move the sound driver to before the 2MB mark for it to work (and even then it's not quite right so the sound effect issues are probably related to this). I guess I could display a message if the emulator doesn't support 6MB ROMs, but I'd rather spend the time making levels, which is why you get a message on the first post of this topic saying "use Kega Fusion" instead!

jasonchrist, on 21 September 2011 - 07:48 AM, said:

That's funny, because the top route for the spikes isn't actually impossible. In fact it's the route I take.

Yes, I mentioned that above. I've seen every route being done now except the middle spike one. I guess I need to rethink what "impossible" is when Sonic Retro gets involved...

[Sik]

ColinC10, on 21 September 2011 - 06:00 PM, said:

Spoiler

This line sets the flag that updates the HUD, but for some reason, Sega have used an add instead of a move.

Spoiler

This is an addq, so it actually takes up less space than a move because the source operand is embedded in the opcode itself, not as a parameter. Granted, this is a byte, so they could have probably just used st to get the same effect...

ColinC10, on 21 September 2011 - 06:00 PM, said:

I had to move the sound driver to before the 2MB mark for it to work (and even then it's not quite right so the sound effect issues are probably related to this).

If you're using the YM2612 timers for high accuracy timing, beware that Gens will update the timers every scanline instead of being Z80-cycle accurate. This actually leads to Gens being unable to play samples at the right speed in my sound engine (Echo wants a tick every 1.5 scanlines, Gens gives it a tick every 2 scanlines).

ColinC10, on 21 September 2011 - 06:00 PM, said:

I guess I could display a message if the emulator doesn't support 6MB ROMs, but I'd rather spend the time making levels, which is why you get a message on the first post of this topic saying "use Kega Fusion" instead!

May want to not assume it's an emulator though, since many flashcarts don't support the entire mapper. In general they only support up to 5MB, and only support switching in the last two pages (which is everything SSF2 uses).

[GerbilSoft]

ColinC10, on 21 September 2011 - 06:00 PM, said:

I'm not sure what you mean here. I use bankswitching to access everything from 4MB to 6MB, which works fine on both Fusion and Gens. Although, Gens seems to be a bit more picky about where you put things on the ROM: I had to move the sound driver to before the 2MB mark for it to work (and even then it's not quite right so the sound effect issues are probably related to this). I guess I could display a message if the emulator doesn't support 6MB ROMs, but I'd rather spend the time making levels, which is why you get a message on the first post of this topic saying "use Kega Fusion" instead!

I just double-checked the Gens/GS r7 code, and it does seem that SSF2 bankswitching support is implemented for up to 8 MB, though it won't allow loading more than 6 MB. Gens/GS II is limited to 5 MB, though I didn't notice any irregularities on first glance when I loaded Sonic VR.

What I'd recommend doing is adding checksums for each 512 KB bank and verifying all the banks, and printing a message if any of them failed. This would make debugging SSF2 emulation a lot easier. (You could also add some flag to the header to disable this to speed up loading.)

EDIT: Gens doesn't properly map the bankswitching system to the 68000 emulator's instruction fetch code. I'd recommend restricting code execution to the first 512 KB, and only use the higher banks for data fetches.

This post has been edited by GerbilSoft: 22 September 2011 - 06:24 PM

[ColinC10]

GerbilSoft, on 22 September 2011 - 06:20 PM, said:

I just double-checked the Gens/GS r7 code, and it does seem that SSF2 bankswitching support is implemented for up to 8 MB, though it won't allow loading more than 6 MB. Gens/GS II is limited to 5 MB, though I didn't notice any irregularities on first glance when I loaded Sonic VR.

What I'd recommend doing is adding checksums for each 512 KB bank and verifying all the banks, and printing a message if any of them failed. This would make debugging SSF2 emulation a lot easier. (You could also add some flag to the header to disable this to speed up loading.)

EDIT: Gens doesn't properly map the bankswitching system to the 68000 emulator's instruction fetch code. I'd recommend restricting code execution to the first 512 KB, and only use the higher banks for data fetches.

I'm really sorry GerbilSoft, I'm not as intelligent or experienced as you are so I've no idea what the fuck you're talking about.

If Gens is more accurate than Kega Fusion at emulating Mega Drive hardware, then it would be really useful for myself and other hackers if you could give a brief list of what the differences are in simple terms that idiots like myself can understand. For example: "When using bankswitching, only execute code in the first 512 KB, and use the higher banks for data fetches". That way I can correct the errors in Sonic VR, and other people might be able to fix these kind of mistakes as well.

If Kega Fusion is more accurate then I don't really care what limitations Gens has. I usually try to support as many emulators as possible, but this year I'm short on time so I'll leave my message on the first post that says "use Kega Fusion".

[Josh]

Really fun hack, though I didn't have nearly the problems some people did. The most a single level took me to do was maybe like 4 or 5 tries. Really clever stuff, and I hope you'll have more for us soon! I freakin' love your hacks; I still play Robotnik's Revenge really often.

[Sik]

ColinC10, on 22 September 2011 - 10:08 PM, said:

I'm really sorry GerbilSoft, I'm not as intelligent or experienced as you are so I've no idea what the fuck you're talking about.

Just make an alternate version of the hack that checksums all 6MB and complains if it fails =P

ColinC10, on 22 September 2011 - 10:08 PM, said:

If Kega Fusion is more accurate then I don't really care what limitations Gens has. I usually try to support as many emulators as possible, but this year I'm short on time so I'll leave my message on the first post that says "use Kega Fusion".

The whole point of his request is to help make Gens more accurate

[ColinC10]

Sik, on 23 September 2011 - 02:31 AM, said:

The whole point of his request is to help make Gens more accurate

I've reread his post now that I'm sober. It makes a little more sense now.