• This forum is strictly intended to be used by members of the VS Battles wiki. Please only register if you have an autoconfirmed account there, as otherwise your registration will be rejected. If you have already registered once, do not do so again, and contact Antvasima if you encounter any problems.

    For instructions regarding the exact procedure to sign up to this forum, please click here.
  • We need Patreon donations for this forum to have all of its running costs financially secured.

    Community members who help us out will receive badges that give them several different benefits, including the removal of all advertisements in this forum, but donations from non-members are also extremely appreciated.

    Please click here for further information, or here to directly visit our Patreon donations page.
  • Please click here for information about a large petition to help children in need.

The nuking of Undertale: Part 2 out of 6 or 7 | "Faster than Sound? Not even Faster than a car."

Status
Not open for further replies.
but only for attack speed, yes? I don’t wanna wake up one day and randomly see it being the reason for travel speed as well lol
Naturally, yeah. Attack or Combat speed only. Undyne in training can land hits on Asgore, and Papyrus is considered really "tough" by Undyne.
 
Actually

(mentioning you cause you were the one that accepted the calc)
Wouldn't the timeframe need 1 more second added to it via the time it takes for the "ring... ring..." (basically the time it takes for papyrus to answer the call after you call him)?

Basically minimal change but just asking for the sake of accuracy.
The ringing variant of the calc also just got accepted btw
 
better than nuthin' unless Strym manages to hard counter this thread.
Still thinking of an answer, plus today was kinda full.
The sound feats are the ones Strym seems to be most interested in replying to. Even then, I think the Blasters are faster.
I am discussing about the electricity stuff rn with also some people off-site.
 
The ringing variant of the calc also just got accepted btw
I think it's better to use that end, will update it if Eden agrees with that.

As for the Asgore one,
just wanna say I still fully disagree with using 1/30 for the timeframe and the counter does not convince me whatsoever considering I showed that the movement is still occuring in a later frame, so the 1 frame being the entire movement does not make sense regardless even ignoring the graphics limitations, will wait for Armor's (or any CGM) input/reasoning on that.
 
Maybe make two ends for the Asgore calc (high + low) and then have people decide? The process seems quicker that way since the calcs’ll be prepared as we wait for input on which one is best
 
I think it's better to use that end, will update it if Eden agrees with that.

As for the Asgore one,
just wanna say I still fully disagree with using 1/30 for the timeframe and the counter does not convince me whatsoever considering I showed that the movement is still occuring in a later frame, so the 1 frame being the entire movement does not make sense regardless even ignoring the graphics limitations, will wait for Armor's (or any CGM) input/reasoning on that.
So please reply, why does the game still register damage in a singular frame if Asgore has not physically moved there in a singular frame.

If the intent was to have Asgore's movement last 3 frames, that would be the window to register damage, no? Also, the visual argument could easily be afterimages from sheer speed imo.
 
So please reply, why does the game still register damage in a singular frame if Asgore has not physically moved there in a singular frame.
Simple Answer: Graphics limitation

Long Answer: Undertale as you already accepted is a game with limited graphics capability, because of this, Toby's sprites for the attack were only 3. So, to make the attack do damage, Toby put the damage inside the Asgore sprite itself during the timeframe between frame 5 and 6 of the animation which is the timeframe when the attack is covering the entire box (the 2 frames where the battle box is covered in orange as I showed in that image with all of them), this is not meant to represent the entire movement but simply the timeframe in when the trident was traveling through the battle box. So the "1 frame" is simply the part of the movement when, if we had it at smoother graphics, Asgore's trident would be traveling through the battle box from the beginning to end. This is not the entire movement (therefore the issue Eden pointed out), as there's still the movement before reaching the box and the end part as I showed. Yall are going too far at this point for the upgrade, the afterimages argument also makes no sense considering you think asgore had already finished the movement on frame 1, so his head would already be positioned to the side and it'd look something like this. Like cmon do you not see his head moves to symbolize the movement is still being made.
ji7oytJ.png

It is very clearly not meant to be an afterimage and simply a connection between the frames otherwise his head would already be in the last position since frame 1 or you're claiming that's also an aftereffect which atp man just making excuses.

As I said I will wait for any CGM to talk on this, I think it's blatantly not one frame and the damage argument does not convince me a single bit since it's just graphics limitation but with more steps.

While at it, for the frame that you all are claiming is the one where he made the entire distance because "Oh look at the movement reaching the end", search on google "What are in-between frames?"
 
Last edited:
Simple Answer: Graphics limitation

Long Answer: Undertale as you already accepted is a game with limited graphics capability, because of this, Toby's sprites for the attack were only 3. So, to make the attack do damage, Toby put the damage inside the Asgore sprite itself during the timeframe between frame 5 and 6 of the animation which is the timeframe when the attack is covering the entire box, this is not meant to represent the entire movement but the timeframe in when the trident was traveling through the battle box. So the "1 frame" is simply the part of the movement when, if we had it at smoother graphics, Asgore's trident would be traveling through the battle box from the beginning to end. This is not the entire movement, as there's still the movement before reaching the box and the end part as I showed. Yall are going too far at this point for the upgrade, the afterimages argument also makes no sense considering you think asgore had already finished the movement on frame 1, so his head would already be positioned to the side and it'd look something like this. Like cmon do you not see his head moves to symbolize the movement being made.
ji7oytJ.png

It is very clearly not meant to be an afterimage otherwise his head would also be moving as one.

As I said I will wait for any CGM to talk on this, I think it's blatantly not one frame and the damage argument does not convince me a single bit since it's just graphics limitation but with more steps.
Fair enough.

I don't think it's graphics limitation, BUT, I do think you're right about this. In fact, I'll say it's likely on frame 5, and not frame 4. I've done some digging in the code. And turns out I'm wrong about the one frame thing.

Undertale has two separate layers operating simultaneously: the rendering layer (sprites, visual frames) and the logic layer (hitboxes, damage registration, collision detection).

qMJeR7L.png


The rendering and logic are literally separate code blocks.
qwRgzYp.png

4uCIfmN.png


eventtype="3" (Step event) handles all damage logic. eventtype="8" (Draw event) handles all visuals. These are completely independent execution paths. This is the two-layer argument proven in the actual source. Graphics limitations affecting the draw event have zero mechanical relationship to what fires in the step event.


The damage window is conditional.

YJ7lkIh.png


Here.
event_user(0) is the damage call.

So damage only occurs when the animation reaches frame =>5 but <6. hitted == 0.

So the damage only applies in the frame 5, which refer to this sprite:
M9YW5Lp.png

Consistent with what you've brought up. But happens at frame 5. Considering the movement starts at frame 1, and not 0, it's a 4 frame window to move, 5 frame movement.

5/30, not 1/30
 
Quick question, does the code run on any specific FPS other than 30?
Cause if it’s like 60 or 25 that could change the result quite a bit
 
Asgore calc changed

I'm really tired rn, so if there it's anything wrong please let me know and i will fix it tomorrow.

Note: Yes, i counted every single pixel
Huh, neat, wall+. That’s pretty good. If it gets accepted and the calc is applied to the crt, would the AP also have to be applied or would that be a different subject since this thread is about speed and not AP?
 
Ykw, we could be doing a hell of a lot worse than 9-B+ and nearly baseline Subsonic+


If all other scaling avenues fail, l'd be fine with this
 
Last edited:
I think my argument is almost finished, but before saying something, is there something in the code mentioning about MTT's bolts accelerating instead of just feeling like that due to spreading out?
 
I think my argument is almost finished, but before saying something, is there something in the code mentioning about MTT's bolts accelerating instead of just feeling like that due to spreading out?
Theeere we go.

We can see this in obj_mettheart_1.object.gmx (first heart pattern)
bwFLjXT.png


This spawns frames 60, 66, 72, etc.

Each bullet:
  • speed = 2
  • friction = -0.1
friction = -0.1 means bullets accelerate over time. Since it's negative friction, and normally that would slow the bullet down.

Bro this code sucks ass-
 
So damage only occurs when the animation reaches frame =>5 but <6. hitted == 0.

So the damage only applies in the frame 5, which refer to this sprite:
M9YW5Lp.png

Consistent with what you've brought up. But happens at frame 5. Considering the movement starts at frame 1, and not 0, it's a 4 frame window to move, 5 frame movement.

5/30, not 1/30
This is technically slightly wrong.

The damage occurs on frame index 5. Since it's zero-indexed, that's the 6th frame out of 7. You can see from his sprite sheet that this is the sprite where the attack covers the full box and he's mid-swing; the one after the sprite you posted here.
Bro this code sucks ass-
Proof that even yandev-tier programmers can be fine, as long as they're goated elsewhere and make choices that suit their skills.
Would you guys be willing to hear me out?
Of course.
 
My god, I haven't been gone that long, how has this gotten so big? Can anyone tell me what happened while I was gone? The arguments seem to have changed a little
 
Status
Not open for further replies.
Back
Top