That was an issue on my end. The encoder crashed in DEZ2, and I didn't pass --shortest when adding sound to the video. I am very short on both hard drive space and patience, so I just said fuck it. I'll likely upload the ending separately when I get around to it.
Why is it when the game loads a moving background or does the results screen for Launch Base or Sonic stands on a flamethrower in Flying Battery the game has to draw a bunch of garbage behind the scenes?
It doesn't _have to_. In reality, if you were just standing there, it wouldn't update the screen at all - it only updates when scrolling. This program simply reads the level data, and interprets it in the format it knows about, every frame. During a transition, half the data has been written, but the other half wasn't; thus, when drawing the level, the renderer will draw the partial data how it sees fit. The flamethrower thing is a separate issue, it has to do with a bug in the renderer that doesn't quite know how to draw flamethrowers correctly - I might've missed handling some object property. I will have to fix that if I ever do a proper encode of this.
I just want to say that smooth camera move can be done using velocity approach, in other words, depending on difference, calculate velocity and then move towards target with the velocity. and other nifty approach: use motion blur formula: last_position*(1-coef)+target_position*(coef) where coef in range from zero to one. coef 1 means instant change, 0.5 means... slower, you can tune value :)
@@Selicre motion blur formula is not motion blur. just same formula but for position instead of pixels. Sorry, I don't know what you mean by juming around in LR2. And of course you need to handle stage transitions when camera is moved instantly.
Hey, Selicre. You mentioned several months ago that you were working on an improved version of this encode. I look forward to it. Has there been any progress lately?
Good question. Moving on, .. Okay, just kidding. I did make some improvements, but none that I can show. I've mostly been interested in other projects and real-life work, because a man's gotta eat, but I'll make sure to start working at this again sometime later. The submission text isn't ready yet either, so I don't feel too bad about slacking.
@@Selicre Haha. Thank you for the heads-up. I hope you decide to stop slacking soon because I won't unbox my new huge TV until your encode is ready. :D
@@Zeupar Oh jeez, that's some pressure on me. Is your TV 4K? Because I might make an encode where it's drawn on a 4K canvas instead of a 1080p one, but I'm not sure if I should go the extra mile given that it already takes quite a long time to render.
@@Selicre It's not 4K, but I strongly recommend you to go for it, as it's the future and probably worth the extra time. By the way, would a monetary incentive help things?
@@Zeupar I've considered making a patreon when I start making Atlas encodes or working on deconstructing other games (I'm currently working on extracting sprites from a few hamtaro games), but for now I feel like it'd be a bit weird given that I don't post updates that often. That said, if you _do_ wanna support me because you like what it is turning out to be already - or when it gets released as a finished version, I have paypal dot me slash x10A94.
![[TAS] Sega Atlas: Sonic 1 any% (no zips) by Aglar](http://i.ytimg.com/vi/0mIjjLUYZRQ/mqdefault.jpg)
![[TAS] Sega Atlas: Sonic 1 any% (no zips) by Aglar](/img/tr.png)
This is the only way to watch this kind of run. Nice work!
1:22:32 Top 10 worst issues in TH-cam...
That was an issue on my end. The encoder crashed in DEZ2, and I didn't pass --shortest when adding sound to the video. I am very short on both hard drive space and patience, so I just said fuck it. I'll likely upload the ending separately when I get around to it.
this is so beautiful , great job!
Why is it when the game loads a moving background or does the results screen for Launch Base or Sonic stands on a flamethrower in Flying Battery the game has to draw a bunch of garbage behind the scenes?
It doesn't _have to_. In reality, if you were just standing there, it wouldn't update the screen at all - it only updates when scrolling. This program simply reads the level data, and interprets it in the format it knows about, every frame.
During a transition, half the data has been written, but the other half wasn't; thus, when drawing the level, the renderer will draw the partial data how it sees fit.
The flamethrower thing is a separate issue, it has to do with a bug in the renderer that doesn't quite know how to draw flamethrowers correctly - I might've missed handling some object property. I will have to fix that if I ever do a proper encode of this.
very good!
very good this disgusting lazy
I just want to say that smooth camera move can be done using velocity approach, in other words, depending on difference, calculate velocity and then move towards target with the velocity.
and other nifty approach: use motion blur formula: last_position*(1-coef)+target_position*(coef)
where coef in range from zero to one. coef 1 means instant change, 0.5 means... slower, you can tune value :)
Motion blur is definitely going to make this unwatchable. Also, how would you handle the camera jumping around in e.g. LR2?
@@Selicre motion blur formula is not motion blur. just same formula but for position instead of pixels.
Sorry, I don't know what you mean by juming around in LR2. And of course you need to handle stage transitions when camera is moved instantly.
@@r75shell Ahh, I see. In all honesty, I might just hardcode some stuff.
Hey, Selicre. You mentioned several months ago that you were working on an improved version of this encode. I look forward to it. Has there been any progress lately?
Good question.
Moving on, ..
Okay, just kidding. I did make some improvements, but none that I can show. I've mostly been interested in other projects and real-life work, because a man's gotta eat, but I'll make sure to start working at this again sometime later. The submission text isn't ready yet either, so I don't feel too bad about slacking.
@@Selicre Haha. Thank you for the heads-up. I hope you decide to stop slacking soon because I won't unbox my new huge TV until your encode is ready. :D
@@Zeupar Oh jeez, that's some pressure on me. Is your TV 4K? Because I might make an encode where it's drawn on a 4K canvas instead of a 1080p one, but I'm not sure if I should go the extra mile given that it already takes quite a long time to render.
@@Selicre It's not 4K, but I strongly recommend you to go for it, as it's the future and probably worth the extra time. By the way, would a monetary incentive help things?
@@Zeupar I've considered making a patreon when I start making Atlas encodes or working on deconstructing other games (I'm currently working on extracting sprites from a few hamtaro games), but for now I feel like it'd be a bit weird given that I don't post updates that often. That said, if you _do_ wanna support me because you like what it is turning out to be already - or when it gets released as a finished version, I have paypal dot me slash x10A94.
Oi