• Emulator used: Gens 11b, and the customized Gens 11b + Camhack + SolidityViewer + HitboxDisplay together with LUA HUD for Genesis Sonic games
  • Aims for fastest ingame time
  • Takes damage to save time
  • Abuses programming errors
  • Does not use zips
  • Manipulates luck
This is a run of Sonic the Hedgehog where no zipping mechanism is abused. It's by no means a glitchless run, mainly because defining what is a glitch and what is not a glitch isn't really trivial. By choosing to not use zipping it means (as defined by me) that what's not allowed to do is gaining a big speed boost (16-32 pixels per frame) from being inside terrains. Something which might seem similar to zipping and is allowed is terrain-ejection and sprite-ejection where the character doesn't gain any speed but instead gets directly shifted to a certain position.
By setting up a goal like this it pretty much forces you to actually play the game like the programmers intended, and you'll never see the screen scroll through the levels without Sonic on it (except when he's above the screen), which more and more have been the case with the Sonic games for Genesis. In this game zips have been found in 13 out of 19 levels (that sometimes basically skip entire levels) meaning that a run without zips looks very different as a whole, which was also a big reason why I made this run.

More details about why this goal was chosen

Normally improvements to Sonic games have been the result of slighty better precision added to the run but mainly by finding more places to zip through thus taking away more and more normal gameplay from the run. When reading through submission threads for many of these improvements it's clear that there's interest for a so called "glitchless" run without anyone really specifying what they mean by that. It might seem like a simple thing to do but if you spend some time with the game learning the physics and everything that comes with it, it'll be clear that it's not so simple - especially when you also need to consider everyone's own opinion of what a glitch is, what a zip is and what an ejection is. As I don't consider ejection a glitch (it's the result of normal collision detection) and pretty much all other things that could be interpreted as glitches besides zipping isn't really noticable by the eye and unintendedly happen frequently when playing the game unassisted. I thus went for only disallowing zipping.
Most criticism has been pointed towards the ejections that skips parts of the levels in the acts SBZ2 and SBZ3. Believe me, I'd be very glad myself if those maneuvers weren't possible as I always wanted to take the intended route. But if I'd disallowed those then the question would be why I didn't disallow other slighty less obvious ejections as well. And then if I'd ban those too, I'd be wondering whether I'd give up even less obvious ejections, and so on until I'd gotten to the kind of ejection that occurs when normally landing on ground which is impossible to not abuse. So rather than setting an arbitrary standard for how "big" the ejection can be in order to stay in the run I simply allowed them all. Of course, I probably just could've skipped using the ejections in SBZ2 and SBZ3 and Final Zone and not mentioning the ejections in the submission text at all, and almost nobody would've noticed the other ejections in the run even if they're there, if I'd just wanted to have this run published as easy as possible, lying is an easy way to get love from people. But then I'd end up with a run that doesn't follow my goals which not how I make my TASes.

Time table

ActMy timePrevious best non-zipped time
Green Hill 10:24:230:24:30
Green Hill 20:17:090:17:43
Green Hill 30:30:450:30:48
Marble Zone 10:42:370:44:26
Marble Zone 20:49:540:52:48
Marble Zone 31:11:331:12:56
Spring Yard 10:21:310:22:12
Spring Yard 20:26:120:28:00
Spring Yard 30:55:400:56:59
Labyrinth 10:39:310:40:45
Labyrinth 20:50:290:51:19
Labyrinth 31:03:421:07:31
Star Light 10:21:230:21:43
Star Light 20:15:130:15:58
Star Light 30:35:260:42:49
Scrap Brain 10:37:51N/A
Scrap Brain 20:33:580:41:18
Scrap Brain 30:15:380:18:26
Final Zone1:12:011:13:20

Level-by-level comments

Green Hill 1

Took use of lots of down-slopes to speed up the jumps, attacked enemies to minimize air drag(1) and jumped an extra time in the loop.

Green Hill 2

Executed the ejection process better and again minimizing air drag.

Green Hill 3

Faster boss fight

Marble Zone 1

I got under the first frame rule based obstacle one frame rule earlier, but then I had to wait to get it right with the platform that goes in and out of the wall.

Marble Zone 2

Just better execution for every situation

Marble Zone 3

Only optimizations

Spring Yard 1

Took the speed shoes in a faster way and using a different route in the middle part of the act.

Spring Yard 2

I gained 3 frames before the second spike ball in the tunnel which just allowed me to pass under it for a big improvement.

Spring Yard 3

Optimizations and a new boss strategy

Labyrinth 1

Optimizations and strategy changes

Labyrinth 2

Took the invincibility to not have to stop and wait for obstacles under the water.

Labyrinth 3

Just lots of optimizations and strategy changes

Star Light 1

Gained more speed pretty much everywhere.

Star Light 2

Gained much more speed and tackled the end better.

Star Light 3

Major shortcut and route change together with a new boss strategy

Scrap Brain 1

Took the only route that doesn't force you to wait for the blocks that go in and out of the wall.

Scrap Brain 2

Used the, by now, famous trick to skip down a level plus a much more optimized last room.

Scrap Brain 3

Optimizations and the other famous trick.

Final Zone

Pausing in the beginning will increase the counter for when the boss fight will start, while not costing any ingame time.
(1) Air drag occurs when your jumping velocity is between -1024 and 0, and takes away 1/32th of your speed per frame.

Thanks to

marzojr for all the help during the making of this run. And thanks to all the previous TASers and contributors to this game, I won't mention any names since I'll probably miss out quite a few, but you know who you are.
Enjoy!

feos: HD Encode.
adelikat: Judging.
adelikat: Accepting for publication as a new category for this game. See this post for my comments.
OmnipotentEntity: Encoding underway.

1 2
5 6
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14843
Location: 127.0.0.1
This topic is for the purpose of discussing #3378: Aglar's Genesis Sonic the Hedgehog "no zips" in 17:36.58
Former player
Joined: 9/1/2005
Posts: 803
That was pretty smooth. I think it's the first time that I've seen scrap brain 1 and 2 actually done normally in a tas. That slick move at the start of starlight zone 3 was worth a yes vote in and of itself.
Exostum
He/They
Joined: 10/14/2009
Posts: 31
Location: France
I have just watched it. I wanted to vote yes, but unfornatuly I am voting no for three reasons : - You don't get all the emarald, so you get the bad ending. - You have use a zipping mechanic in the last battle. I was so pissed that I closed the emulator... This is the reason that demote my vote from a weak yes to a strong no. So my vote is a strong no. I will vote yes for a true "no zipping, true ending" run of sonic 1 This is a little sad because the run is pretty well made, but It is my opinion... so sorry.
May the moon and the sun of arkantothia protect you.
Expert player (3560)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
finalserafin wrote:
I have just watched it. I wanted to vote yes, but unfornatuly I am voting no for three reasons : - You don't get all the emarald, so you get the bad ending. - You have use a zipping mechanic in the last battle. I was so pissed that I closed the emulator... This is the reason that demote my vote from a weak yes to a strong no. So my vote is a strong no. I will vote yes for a true "no zipping, true ending" run of sonic 1 This is a little sad because the run is pretty well made, but It is my opinion... so sorry.
1. I don't use zipping in the Final Zone, it's sprite ejection as explained in the submission text. 2. An all emerald run would be more boring in my oppinion, and such a run has already been rejected.
feos wrote:
Only Aglar can improve this now.
Skilled player (1705)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Aglar wrote:
1. I don't use zipping in the Final Zone, it's sprite ejection as explained in the submission text.
Seems kinda similiar in my opinion. =/ To be exact, isn't zipping just the game trying to eject you out of the game's terrian? So even though your trick might not give a large speed boost, it still (sorta) counts as "zipping". =p
Expert player (3560)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
jlun2 wrote:
Aglar wrote:
1. I don't use zipping in the Final Zone, it's sprite ejection as explained in the submission text.
Seems kinda similiar in my opinion. =/ To be exact, isn't zipping just the game trying to eject you out of the game's terrian? So even though your trick might not give a large speed boost, it still (sorta) counts as "zipping". =p
Well, I suppose the difference is hard to tell if you're not familiar with the concepts. What's banned in ths run is the mechanism that lets you gain "real speed" (not just changes your position) from inside terrains that's kept when you're outside of it, and no such maneuver is used in this run.
feos wrote:
Only Aglar can improve this now.
Joined: 7/2/2007
Posts: 3960
Sprite ejection is a fundamental part of having solid terrain in a game. The way terrain usually works is that the sprite embeds itself in the wall (when its velocity is added to its position) and then is ejected from it before drawing ever occurs. This gives the appearance of the sprite having stopped bang on the terrain, even though that's not what "really" happened. In the ideal case the sprite would be ejected along the reverse of its velocity vector, but sometimes it's ejected along the shortest path -- which is how you can get e.g. horizontal boosts in some games by clipping the back corners of floating platforms. Zipping is different -- it's the game trying to gracefully handle an error condition. Zipping usually occurs when the game tries to do its usual ejection, but that ends up embedding the sprite in a different terrain tile, which would eject the sprite back in the first direction again -- an infinite loop. So instead the game applies some arbitrary velocity vector (and optionally turns off terrain intersection for a bit) to try to get the sprite out of the terrain entirely. The two are qualitatively different and I have no problem with a run that uses the former but not the latter. That said, I haven't watched this run yet and thus can't vote.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 11/23/2011
Posts: 4
Location: Manchester, England
I noticed there was a pause for a few frames in the Final Zone before entering the battle, was that to manipulate the boss position perhaps?
Patryk1023
He/Him
Joined: 3/1/2011
Posts: 288
Location: Inside out house.
Psychemaster wrote:
I noticed there was a pause for a few frames in the Final Zone before entering the battle, was that to manipulate the boss position perhaps?
Propadly yes.
<Nach> scrimpy is fretty with her sunglasses on I'm here. never visible.
Expert player (3560)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Psychemaster wrote:
I noticed there was a pause for a few frames in the Final Zone before entering the battle, was that to manipulate the boss position perhaps?
Actually no, it's done to start the boss fight 79 ingame frames earlier in that level. I'll add the details to the submission text tomorrow.
feos wrote:
Only Aglar can improve this now.
Joined: 2/20/2010
Posts: 209
Location: I'm in space
From reading the above posts, my impression is that this run simply refrains from using a particular glitch that - to an untrained eye - resembles another glitch that IS still exploited. I haven't watched it yet, but I think my vote will really depend on whether I, a TAS layperson, would agree with Derakon that the omitted glitch substantially changes the run. And I don't mind that the emeralds weren't collected.
Oh, play it cool. Play it cool. Here come the space cops.
Editor
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
I do not like this run because it does "zip." Reading this artice: http://tasvideos.org/GameResources/Genesis/SonicTheHedgehog.html It explains how Sprite Ejection and Terrain Ejection work. All that's different here is that Left+Right was not pushed at the time of the check. Sure you don't get a speed boost, but you still violated the game's rules concerning solid objects. I am voting No one this since you made arbitration and then didn't follow it. Play the game with out glitching it. I would love to see a Sonic game with out abusing glitches. That and a 100% run of Sonic 1 and 2.
When TAS does Quake 1, SDA will declare war. The Prince doth arrive he doth please.
Expert player (3560)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
hegyak wrote:
I do not like this run because it does "zip." Reading this artice: http://tasvideos.org/GameResources/Genesis/SonicTheHedgehog.html
I read that too before starting the run, believe it or not. ________________________________________ Terrain Ejection If a player character becomes partially lodged in terrain, there are two separate ejection mechanisms. First, it runs the same set of tests as sprite-based ejection. If that test fails, it checks to see if the player is holding left or right, and, if the player is holding left or right, it gives the player a variable speed (based on distance from the edge of the terrain tile) between 16 and 32 pixels per frame, in the direction opposite the one they are holding. This ejection routine (commonly known as zipping) will not trigger if the player is falling. ____________________________________________ The mechanism the text in bold explains (coincidently named zipping) never happens.
feos wrote:
Only Aglar can improve this now.
Joined: 3/22/2008
Posts: 84
I haven't seen the run (desynchs with the ROM i have, and I'm too lazy to look for yours), but a lot of people watch runs like this because it shows off the entire game. When you remove one game-breaking glitch only to make use of another, it seems pointless. Even worse, in this case, is the fact that the "other" glitch you use functions so similarly to the one that you chose to prohibit. I don't really think either side is correct in this argument, but that fact that it's so divided somewhat of an issue itself.
Joined: 7/2/2007
Posts: 3960
goldfish wrote:
From reading the above posts, my impression is that this run simply refrains from using a particular glitch that - to an untrained eye - resembles another glitch that IS still exploited. I haven't watched it yet, but I think my vote will really depend on whether I, a TAS layperson, would agree with Derakon that the omitted glitch substantially changes the run.
To be clear, sprite ejection is not a glitch. It's a fundamental mechanic of discrete (i.e. non-continuous) physics systems, which basically all games use. You can't detect a collision between two objects before those two objects are actually intersecting; at that point, you have to decide how to fix things so that the objects no longer intersect. Typically this involves backing out one or both of the objects -- sprite ejection -- though plenty of games simply destroy the offending object (c.f. most scrolling shmups). Depending on how many resources you can dedicate to the task (and how skilled of a programmer you are), collision response can be more or less accurate, but in any case it's not a glitch. Zipping is the game going "oh crap, my usual routines for fixing object intersection aren't working." Sprite ejection is perfectly normal and expected behavior whenever two objects bump into each other. That's why they're qualitatively different.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Expert player (3560)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
mapler90210 wrote:
When you remove one game-breaking glitch only to make use of another, it seems pointless.
Zipping can make you skip entire levels, while ejection makes you skip a few pixels. What's your definition of a game-breaking glitch?
feos wrote:
Only Aglar can improve this now.
Exostum
He/They
Joined: 10/14/2009
Posts: 31
Location: France
Aglar wrote:
finalserafin wrote:
I have just watched it. I wanted to vote yes, but unfornatuly I am voting no for three reasons : - You don't get all the emarald, so you get the bad ending. - You have use a zipping mechanic in the last battle. I was so pissed that I closed the emulator... This is the reason that demote my vote from a weak yes to a strong no. So my vote is a strong no. I will vote yes for a true "no zipping, true ending" run of sonic 1 This is a little sad because the run is pretty well made, but It is my opinion... so sorry.
1. I don't use zipping in the Final Zone, it's sprite ejection as explained in the submission text. 2. An all emerald run would be more boring in my oppinion, and such a run has already been rejected.
1) We have a different opinion here : zipping and sprite ejection are the same to me. 2) We have a different opinion here also : I consider that a game must be 100% completed. Everyone has their own opinion, this is just mine. In any case, the category is too personal (ed: arbitrary?) to be published, and the run doesn't achieve its goal anyway (because it uses zips), which is the main reason why I voted no. The fact that the emeralds are skipped is a comparatively minor issue (my vote would have been a weak "yes" if there had been no zips). Edit : Replaced french with Derakon's traduction of my post. Thanks to derakon.
May the moon and the sun of arkantothia protect you.
Joined: 7/2/2007
Posts: 3960
A quick and dirty translation of finalserafin's post: "Everyone has their own opinion, this is just mine. In any case, the category is too personal (ed: arbitrary?) to be published, and the run doesn't achieve its goal anyway (because it uses zips), which is the main reason why I voted no. The fact that the emeralds are skipped is a comparatively minor issue (my vote would have been a weak "yes" if there had been no zips)." I've made my case for why zips and ejections are different, but of course I've yet to view the movie to see if ejections are abused, so to speak.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Expert player (3560)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
I didn't really expect this kind of rage against the ejection. I can just inform you that given how this game works, a run strictly without ejection can't be made at all, since that would require that you not only must hit each wall with a speed of less than a pixel per frame, but also land every jump with a y-speed off less than a pixel per frame (which even if it was possible would made for an extremelly stupid looking run). And thus I allow all ejection no matter how small or big. Or maybe you think the goal would've been less arbitrary if I had set an unmotivated upper bound of how many pixels I can be skifted?
feos wrote:
Only Aglar can improve this now.
Editor
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
I say that Sprite Ejection as used in this run, is still zipping. All that's different, is you don't get ejection velocity from it. You still gained the effect of skipping almost all of Scrap Brain 3. At worst, it's zipping, at best, your too arbitrary with this run since you can do Sprite Ejection, but not Terrain Ejection. How about a no glitch run? Then things are clear. Edit: Normal Sprite Ejection (killing enemies) is perfectly acceptable since the programmers intended this, but glitching in Scrap Brain 3, was NOT their intent. My vote stands due to this.
When TAS does Quake 1, SDA will declare war. The Prince doth arrive he doth please.
Expert player (3560)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
hegyak wrote:
At worst, it's zipping, at best, your too arbitrary with this run since you can do Sprite Ejection, but not Terrain Ejection. Then things are clear.
Submission Text wrote:
Something which might seem similar to zipping and is allowed is terrain-ejection and sprite-ejection
By this I meant the terrain ejecation that doesn't fail the first check.
hegyak wrote:
How about a no glitch run?
Derakon wrote:
To be clear, sprite ejection is not a glitch. It's a fundamental mechanic of discrete (i.e. non-continuous) physics systems, which basically all games use. You can't detect a collision between two objects before those two objects are actually intersecting; at that point, you have to decide how to fix things so that the objects no longer intersect. Typically this involves backing out one or both of the objects -- sprite ejection -- though plenty of games simply destroy the offending object (c.f. most scrolling shmups). Depending on how many resources you can dedicate to the task (and how skilled of a programmer you are), collision response can be more or less accurate, but in any case it's not a glitch. Zipping is the game going "oh crap, my usual routines for fixing object intersection aren't working." Sprite ejection is perfectly normal and expected behavior whenever two objects bump into each other. That's why they're qualitatively different.
and if you still don't agree:
Aglar wrote:
I can just inform you that given how this game works, a run strictly without ejection can't be made at all, since that would require that you not only must hit each wall with a speed of less than a pixel per frame, but also land every jump with a y-speed off less than a pixel per frame (which even if it was possible would made for an extremelly stupid looking run). And thus I allow all ejection no matter how small or big. Or maybe you think the goal would've been less arbitrary if I had set an unmotivated upper bound of how many pixels I can be skifted?
feos wrote:
Only Aglar can improve this now.
Editor
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
Aglar,
Normal Sprite Ejection (killing enemies) is perfectly acceptable since the programmers intended this, but glitching in Scrap Brain 3, was NOT their intent. My vote stands due to this.
Your submission text says, "By setting up a goal like this it pretty much forces you to actually play the game like the programmers intended" But, your Sprite Ejection on Scrap Brain 3 is NOT what SEGA/Sonic Team intended for the game. If they did, then why go through the effort to make that level? That's why I stand by my vote.
When TAS does Quake 1, SDA will declare war. The Prince doth arrive he doth please.
Expert player (3560)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
hegyak wrote:
Aglar,
Normal Sprite Ejection (killing enemies) is perfectly acceptable since the programmers intended this, but glitching in Scrap Brain 3, was NOT their intent. My vote stands due to this.
Your submission text says, "By setting up a goal like this it pretty much forces you to actually play the game like the programmers intended" But, your Sprite Ejection on Scrap Brain 3 is NOT what SEGA/Sonic Team intended for the game. If they did, then why go through the effort to make that level? That's why I stand by my vote.
"By setting up a goal like this it pretty much forces you to actually play the game like the programmers intended" By this I meant "normal game-play almost everywhere"
feos wrote:
Only Aglar can improve this now.
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
I wholeheartedly support the goal choice; will watch the run tomorrow, but I'm sure there's nothing in it that'll prevent me from liking it. Please consider do the same for other Sonic titles (any of them will do).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 11/23/2011
Posts: 4
Location: Manchester, England
Aglar wrote:
"By setting up a goal like this it pretty much forces you to actually play the game like the programmers intended" By this I meant "normal game-play almost everywhere"
Well the comment still stands that you broke the goals you set for yourself on this run. If I could vote, it'd be a no. =(
1 2
5 6