lemon32767/ccleste

Celeste Classic C source port for 3DS and PC.

ccleste

This is a C source port of the original celeste (Celeste classic) for the PICO-8, designed to be portable. PC and 3DS are the main supported platforms, though other people are maintaining ports to other platforms.

Go to the releases tab for the latest pre-built binaries.

An experimental web port is also available here.

celeste.c + celeste.h is where the game code is, translated from the pico 8 lua code by hand. These files don't depend on anything other than the c standard library and don't perform any allocations (it uses its own internal global state).

sdl12main.c provides a "frontend" written in SDL (plus SDL mixer) which implements graphics and audio output. It can be compiled on unix-like platforms by running

make

By default, SDL2 will be used. Read the Makefile for more information.

3DS is also a supported platform. Compile to 3DS with:

make -f Makefile.3ds    # this will generate ccleste.3dsx

You will need devkitPro with these dkp packages installed:

3ds-sdl
3ds-sdl_mixer
libctru
devkitARM

Controls

PC	3DS	Action
LEFT	LEFT	Move left
RIGHT	RIGHT	Move right
DOWN	DOWN	Look down
UP	UP	Look up
Z/C	A	Jump
X/V	B/X	Dash
ESCAPE	START	Pause
E	L+R	Toggle screenshake
SHIFT+D	Y+L	Load state
SHIFT+S	Y+R	Save state
Hold F9	Hold SELECT+START+Y	Reset
F11	SELECT	Fullscreen

Controller input is also supported on PC (SDL2 ver) and web version. The controller must be plugged in when opening the game. The default mappings are: jump with A and dash with B (xbox360 controller layout), move with d-pad or the left stick, pause with start, save/load state with left/right shoulder, exit with guide (logo button). You can change these mappings by modifying the ccleste-input-cfg.txt file that will be created when you first run the game.

You can make the game start up in fullscreen by setting the environment variable CCLESTE_START_FULLSCREEN to "1", or by creating the file ccleste-start-fullscreen.txt in the game directory (contents don't matter).

TAS playback and the fixed point question

In order to playback a TAS, specify it as the first argument to the program when running it. On Windows you can drag the TAS file to the .exe to do this. The format for the TAS should be a text file that looks like "0,0,3,5,1,34,0,", where each number is the input bitfield and each frame is ended by a comma. The inputs in the TAS should start in the first loading frame of 100m (neglecting the title screen). When playing back a TAS the starting RNG seed will always be the same.

Most other Celeste Classic ports use floating point numbers, but PICO-8 actually uses 16.16 fixed point numbers. For casual play and RTA speedrunning, the discrepancies are minor enough to be essentially negligible, however with TASing it might make a difference. Defining the preprocessor macro CELESTE_P8_FIXEDP when compiling celeste.c will use a bunch of preprocessor hacks to replace the float type for all the code of that file with a fixed point type that matches that of PICO-8. The use of this preprocessor macro requires compiling celeste.c with a C++ compiler, however (but not linking with the C++ standard library).

Using make you can compile this fixed point version with make USE_FIXEDP=1.

When playing back TASes made with other tools that work under the assumption of ideal RNG for balloons (since their hitbox depends on that), you can ensure that they do not desync by defining the preprocessor macro CELESTE_P8_HACKED_BALLOONS, which will make balloons static and always expand their hitbox to their full range.

Using make you can turn on this feature with make HACKED_BALLOONS=1.

You can combine both of these with make HACKED_BALLOONS=1 USE_FIXEDP=1.

credits

Sound wave files are taken from https://github.com/JeffRuLz/Celeste-Classic-GBA/tree/master/maxmod_data, music ogg files were obtained by converting the .wav dumps from pico 8, which I did using audacity & ffmpeg.

All credit for the original game goes to the original developers (Maddy Thorson & Noel Berry).

ccleste's Issues

SDL 2 joysticks are working with the game?

Hello!
SDL 2 joysticks eg. DS4 gamepad, are working with the game?

Implemetation inaccuracy

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:

1. 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

2. 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

.cia version for 3ds

This is great and it works perfectly but it would be nice if I could add it to the home menu and not just have it in the homebrew launcher submenu

Under what license is the code distribute?

Hello, under what license is the code distributed? GPL v2? CC? Public domain?
Thanks!

not able to build with default compiler command order

I have always had to change the compiler command order from the makefile to what is below

$(OUT): sdl12main.c $(CELESTE_OBJ) celeste.h sdl20compat.inc.c
$(CC) sdl12main.c $(CFLAGS) $(CELESTE_OBJ) -o $(OUT) $(LDFLAGS)

installing on pi-apps, not showing up under "games"

some reason installing this from Pi-Apps causes the shortcut to not show up in the start menu under games.

i noticed while it was installing that it cannot find the directory at all.

i am using the newest version of raspian 64bit.

Ability to remap buttons

Preferably, the user should be able to remap the buttons as she wants via some sort of config file. (I know I can just simply recompile with my preferences, but this a bit more hassle in terms of package management). For instance, the game now uses a different button than celeste (the main game) for jumping (on my PS3 controller on Linux).

Scaling the contents of the game window

Thank you so much for this great little project. 😊

Not sure if this is my fault, but currently the content's game window don't really scale nicely (in fact, they seemingly don't do so at all). With this, I mean that the window contents don't react to being launched or changed to a fullscreen window state, nor to any resize events. This is especially cumbersome on HiDPI screens, where the window launches in an incredibly tiny state.

It doesn't get any bigger than this:

If I scale, the following is displayed (also note the artifacts below and next to the game contents, those exist within the window, but obviously outside any "playable" area):

record2021-01-27-1611753188.mp4

I'm on Arch Linux (kernel version 5.10.10), and I use X11.

SDL_N3DSKeyBind(3DS)

The function SDL_N3DSKeyBind has been removed upstream, so now the compiler winges about an undefined reference.

Relevant Info
devkitPro/SDL#58
devkitPro/SDL#65

License of the source code

Hi, I couldn't find information about the license of the source code in the repository. There does not seem to be a license file or license information in the source files. Is it MIT or GPL or something similar? Adding such information would help clarifying how the code can be used.

Not an issue, just some notes

Loving this port but there are a few things that I would like added to your master ccleste repo
I've already hacked them together in my fork https://github.com/theofficialgman/ccleste/tree/upstream_edits but the changes are hacks and not proper implementations

the issue with moving to sdl2 is that now the fullscreen mode places the window in the top left corner of the screen and leftover image data is drawn around the gameplay. this wasn't the case with the sdl1.2 fullscreen which centered the window and did not draw the out of bounds rendering

The gamecontroller api fails to function if the controller which is used does not have a mapping the the global gamecontroller.db file, better to allow the user to load their own

saves/load and exit can't be executed from a controller

all of these have been hacked in through my upstream_edits branch of my fork. they are hacks because they do not care for sdl1.2 compatibility so if/else statements may be needed to ensure compatibility with both versions

Change PC controller input

How can i change the keys from the controller on a PC keyboard?

Crashes on boot New3DS

I attempt to load the ccleste.3dsx (version 1.4) file through homebrew with my New 3DS XL and it simply crashes.
I should note that 1.3.1 works and that in homebrew it shows the default icon with the filename with the description as "Homebrew application" by "Unknown author"
If it matters Luma is my chainloader and safe9boot is my bootloader attached is a zip file with my crashdump:
crash_dump_00000000.zip

Berry does not reappear in 2300M after respawn

This is not the case in the original game as was not the case in the sdl1.2 version from a few months ago