Hi,
first of all I'd like to preface this by saying that this implementation is incredibly faithful to the original, and it's definitely the most accurate full implementation I have ever seen.
That being said, there are a couple of differences between this and the original that i'd like to point out
these are the 2 non visual/audio differences that i know of:
The modulo (%) operator is implemented a bit differently for negative numbers in c and in lua. In c negative%positive=negative, while in lua it's positive (i.e -5%8=-5 in c and 3 in lua). In most places this isn't an issue, however there is one place where it does - a trick called fast 2500:
Basically, your dash goes fast enough to skip over the spikes and into the next level. However, in your version (and also in the version included in the 2018 steam release of celeste) this happens
Basically you get to y<-4 and exit, but because of the faulty modulo checks the game also thinks you're colliding with the spikes, and because of that also it kills you which makes you spawn twice in the next level.
This can be fixed by replacing the modulo checks in spikes_at i.e. a%b with (a%b+b)%b (or you could just use some if statement). I tried replacing this in my own personal c++ implementation of the celeste mechanics, and it did fix it and make it behave like the pico8 version
There's essentially a bug in the original game caused by how lua's foreach works, that in the community we call "loading jank". If you exit a level where the player is the nth object, all the objects from the n+1st onwards loaded in the new room get updated on the frame the room is loaded. On the contrary, in your version none of them get updated. in general this doesn't change much, however it does matter for speedrunning and tasing purposes, and it changes the cycles a bit on cloud levels. You can see how this is fixed in MeepMoop's Pyleste (you basically just compensate for the extra updates manually). Actually, reading the code just now I think Pyleste is not entirely accurate either, because it assumes the player is the last object (which is almost always true) but i'm not 100% sure on that. anyways, it's still a pretty accurate implementation and a good starting point
We have a community discord for celeste and I (or some other knowledgeable people) could elaborate more on these if you join there. In addition, I'd love to discuss this project a bit with you because it's super interesting to me. feel free to ping me if you decide join: @gonengazit#1828
lemon32767
commented
4 years ago
Hi, first of all I'd like to preface this by saying that this implementation is incredibly faithful to the original, and it's definitely the most accurate full implementation I have ever seen. That being said, there are a couple of differences between this and the original that i'd like to point out these are the 2 non visual/audio differences that i know of:
The modulo (%) operator is implemented a bit differently for negative numbers in c and in lua. In c negative%positive=negative, while in lua it's positive (i.e -5%8=-5 in c and 3 in lua). In most places this isn't an issue, however there is one place where it does - a trick called fast 2500:
Basically, your dash goes fast enough to skip over the spikes and into the next level. However, in your version (and also in the version included in the 2018 steam release of celeste) this happens
Basically you get to y<-4 and exit, but because of the faulty modulo checks the game also thinks you're colliding with the spikes, and because of that also it kills you which makes you spawn twice in the next level.
This can be fixed by replacing the modulo checks in spikes_at i.e. a%b with (a%b+b)%b (or you could just use some if statement). I tried replacing this in my own personal c++ implementation of the celeste mechanics, and it did fix it and make it behave like the pico8 version
There's essentially a bug in the original game caused by how lua's foreach works, that in the community we call "loading jank". If you exit a level where the player is the nth object, all the objects from the n+1st onwards loaded in the new room get updated on the frame the room is loaded. On the contrary, in your version none of them get updated. in general this doesn't change much, however it does matter for speedrunning and tasing purposes, and it changes the cycles a bit on cloud levels. You can see how this is fixed in MeepMoop's Pyleste (you basically just compensate for the extra updates manually). Actually, reading the code just now I think Pyleste is not entirely accurate either, because it assumes the player is the last object (which is almost always true) but i'm not 100% sure on that. anyways, it's still a pretty accurate implementation and a good starting point
We have a community discord for celeste and I (or some other knowledgeable people) could elaborate more on these if you join there. In addition, I'd love to discuss this project a bit with you because it's super interesting to me. feel free to ping me if you decide join: @gonengazit#1828
Hope to see you there, Cheers