Posts for Aglar

1 2
6 7 8
14 15
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
GlitchMan wrote:
I have a place where there are maps of each stage that shows you what places you can zip through: http://soniccenter.org/maps/sonic_1 These maps have each level's collision detections. The green areas you can't pass through the top, the red is the inverse of the green (can't pass through the sides and the bottom), and the blue you can't pass through at all (unless a sprite object forces you through). I hope this helps.
Well, that's already very known to us. To be even more clear, this is what I would like to know: Have you found any zip in the Spring Yard Zone?
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Me and marzojr are now up to Spring Yard Zone in the zipped TAS. GlitchMan: If you've found some places to zip here (especially in the first two acts) we would be glad to know that now, since neither of us could find anything.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
wicked wrote:
what is Camhack + SolidityViewer + HitboxDisplay ? where i can get then?
http://www.mediafire.com/file/uw1gls6593v757s/gens_11b-s1.7z User instructions by marzojr: "The modifications are by Upthorn and Nitsuja, I just compiled with it. It has solidity display (green = only top solid; red = all but top solid; blue = all solid; no overlay = not solid) (which can be used to spot imperfections on the ground, which are sometimes good for slope jumps), hitbox display, base RAM address and slope display (can be turned on/off with numlock) and the camhack -- which can still be useful as you can force it to center in an offscreen object (such as the spikes you mentioned) using page up/page down/home to navigate through objects and scroll lock to toggle on/off."
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Thanks for accepting it adelikat! I like the idea of still leaving a door open for a run with less "game breaking" ejections if in the future the game will get more and more broken even without zips, or if someone just feels like doing it. Me and marzojr have also started working on the "zipped" run, so that it's up to date and so the differences between the two categories will be even more distinguishable.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
How to define not going through terrain? For example at around frame 9480 I partially enter the terrain not beacause it's glitch or anything but because the game works that way, I just enter on the first possible frame. Then after a while, when I'm no longer on the platform, I get ejected downwards since that's how the normal procedure goes if more than half of character is outside the terrain before the ejection occurs. For a viewer without the knowledge though the first impression would probably be that I abuse a glitch (if they care to look at in frame advance), and indeed what visually happens is that I enter the wall from the right and come out below it. There's no way I'll make a run which doesn't allow this because it'd look extremelly sloppy, be much more boring and it'd most definitely get complains like "Why did wait there for so long?" or "Why did you overshoot all jumps when jumping to a higher platform?". EDIT: "Taking a route intended by the programmers" would be a slightly better option IMO and would only require me to redo SBZ2 and SBZ3, even though I think that goal is way more arbitrary than the current one.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Submission text updated.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
To answer:
Psychemaster wrote:
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. =(
and:
Noob Irdoh wrote:
I am a true Sonic fan, and as such, I really enjoyed this movie. Nice and different, it actually shows most of the levels in a fashion playable even by hand for the most part (some tricks are still very hard to perform in real time though). The beginning of SYZ3 is epic. However I have to vote no for the arbitrarity of the execution: in SYZ3 you glitch through a loop, in SBZ2 you glitch through the moving thing, not to mention the SBZ3 altogether. I think you should redo those 3 things, since it seems there has been lot of criticism. But I love this low-glitch category. I can\'t believe the day I vote no on a Sonic game would arrive.
In the goals you'll find: Abuses programming errors Feel free to criticize the goals themselves, but please no more talking about me not following them. Either read through the all posts in the thread, come back tomorrow when I'll clear up things in the submission text.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
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.
Experienced Forum User, Published Author, Expert player (3588)
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.
Experienced Forum User, Published Author, Expert player (3588)
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.
Experienced Forum User, Published Author, Expert player (3588)
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.
Experienced Forum User, Published Author, Expert player (3588)
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.
Experienced Forum User, Published Author, Expert player (3588)
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.
Experienced Forum User, Published Author, Expert player (3588)
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.
Experienced Forum User, Published Author, Expert player (3588)
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.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Awesome run, no need to say more! Looks like feos has gotten more interested in pure time attacking now as, opposed to the BTDD run, this time the battletoads didn't battle toads.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Nice to see some interest in the game! I'd rather see an improvement of my warpless run or the 2-player warpless run though. Judging from this submission thread, of the run that obsoleted the warped category, it was obsoleted partially because it was highly improvable but also since they didn't think it was different enough from the warpless and thus wasn't needed - and I pretty much agree with this. I'd most of all like to see an improved version of the 2-player warpless run, since the current one have much room for improvement (especially level 8). The lag management will be very tedious tough which was mostly why I didn't do that run.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
marzojr wrote:
Just a question -- since you mentioned a "no zip" run, I would guess that would entail not zipping in Green Hill zone 2 (or risk the run being rejected for failing to adhere to its own goals). You will be doing that? (and yes, I know that deciding whether or not to use zips is a pain; I have been there...)
Yes, more cleary what's banned in is being inside a wall so that you get a speed of 4096+, while sprite ejection and such are fine. The first zone is already done, and judging by the random factors you mentioned it's seems best to fix the animals right away so I'll PM you the WIP.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
marzojr: How to do with the animal optimization? I think it'll have the best result if you take care of it, as I'm not really comfortable with it. In that case, could I send you the run when it's finished or after each completed world?
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
graywords wrote:
I wonder if a TAS-optimized version of a run like this would go over well? Similar to the published "Contra" pacifist run? It seems like there is lots of entertainment potential to be had.
I thought this sounded familiar: http://tasvideos.org/forum/viewtopic.php?t=6848
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
I guess that as of now, a run with wall-zipping and one without would look different from each others enough to warrant publications for both of them. I'd actually be quite interested in working on the later. And if someone or a few others could try to experiment with the new zipping glitch to find all the best uses for it, they could just be hexed into the non-zip run when it's done (which will take a long time for sure). Anyone interested? And GlitchMan, I might've expressed myself a little harsh to you. It's indeed a good discovery and I'm not upset with you or anything, just slightly with the game itself lol.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Well, that's a big timesaver. I'm rather disappointed though. I've always thought zipping in Sonic games impairs the viewing experience, and now the whole Marble Zone is pretty much ruined in that aspect. It also decreases the TASing experience in creating the run deeply, as I had looked forward to all the non-zipping parts of it most of all. I don't know how many more sprites in the games that are directly attached to walls but I'm now quite unmotivated in continuing the run.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
New WIP: http://dehacked.2y.net/microstorage.php/info/535041267/Sonic%20The%20Hedgehog%20%28W%29%20%28REV%2001%29%20WIP_Aglar.gmv MZ2 suited me as a TASer really well. I didn't improve time to 0:33 but I'm still pleased with the result. I'll check more into the last part of this level later, and also try to have more style during waiting periods. I need to do something about the rerecord count as well, since this wouldn't look too nice in the statistics.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Rolling made me keep the 1536 speed one more frame when hitting the uphill. Landing in an uphill while rolling apparently make it count as flat ground for a frame.
feos wrote:
Only Aglar can improve this now.
Experienced Forum User, Published Author, Expert player (3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
I tested it a little and I'm having trouble with the initial animals, where it seems you need to manipulate all at once - if I've understood it right. Have you gotten a good result out of this? If a rabbit jumps out from the middle it takes about 83 frames for it to leave the screen (after it lands) while it takes 56 frames for a flicky to do so. If a rabbit jumps out from one of the edges and then goes in the best direction it takes 74 frames for it to leave the screen while it takes 49 frames for a flicky. So the maximum difference, given that you manipulate them to go in the best direction after they land is 34 frames which means that to make sure a rabbit doesn't waste time the last 9 animals should be flickys (5 from the initial list and 4 from the spawning list). Most likely it'll be enough for the 7 last animals to be flickys though. Maybe this could be of use for an eventual bot using the script.
feos wrote:
Only Aglar can improve this now.
1 2
6 7 8
14 15