• Most people probably don't realise this, but this forum has had two editors for a number of years. One is the xenForo default editor, and the other is a custom editor I made years back I called BBCEd.

    All the settings for which editor you use was lost during the upgrade. You can find the setting under Account Settings > Preferences > Editor.

CSE2

Sep 13, 2019 at 10:01 PM
Neophyte Member
"Fresh from the Bakery"
Join Date: Aug 5, 2019
Location: Hell
Posts: 6
#81
I doubt it could be that. Just two days ago, I ran the enhanced branch on a device with only 1GB of RAM.
Do you know what else could be causing it?
 
Sep 13, 2019 at 10:20 PM
Senior Member
CSE Discord Admin
"This is the greatest handgun ever made! You have to ask yourself, do I feel lucky?"
Join Date: Jan 13, 2016
Location:
Posts: 102
#82
Nope. If you make a debug build, and run it through gdb, you might be able to track down the cause.
 
Sep 13, 2019 at 10:56 PM
Neophyte Member
"Fresh from the Bakery"
Join Date: Aug 5, 2019
Location: Hell
Posts: 6
#83
Last edited:
Sep 14, 2019 at 1:08 AM
Neophyte Member
"Fresh from the Bakery"
Join Date: Aug 5, 2019
Location: Hell
Posts: 6
#84
Because I don't have a debug build, here's what happened when I ran the current build through:

Code:
(gdb) run
Starting program: /home/lazil/Cave Story/CSE2/Vanilla CSE2 Enhanced/game/CSE2 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec849700 (LWP 29867)]
[New Thread 0x7ffff7fa4700 (LWP 29869)]
[New Thread 0x7fffc3fff700 (LWP 29871)]
*** buffer overflow detected ***: /home/lazil/Cave Story/CSE2/Vanilla CSE2 Enhanced/game/CSE2 terminated

Thread 1 "CSE2" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
Any thoughts?
 
Sep 14, 2019 at 3:11 PM
Monster girl enthusiest
"Keep on rollin'!"
Join Date: Sep 22, 2012
Location: Hugging a tentacle monster
Posts: 438
#85
I have a few very dumb questions about CSE2:
In this folder, create another folder called 'build', then switch to the command-line (Visual Studio users should open the Developer Command Prompt) and cd into it. After that, generate the files for your build system with
This makes no sense to me, never touched a developer command prompt in my life, and I don't know what 'cd into it' means
An automated build.bat and dependencies downloader would be awesome.

Is there a project file? I cannot find one anywhere and am really used to having those available when working in VS (Terraria modding has spoiled me a little)
 
Sep 14, 2019 at 3:22 PM
Senior Member
CSE Discord Admin
"This is the greatest handgun ever made! You have to ask yourself, do I feel lucky?"
Join Date: Jan 13, 2016
Location:
Posts: 102
#86
Google's your friend. The Developer Command Prompt can be found in Windows's start menu, in the Visual Studio folder. 'cd' is a command for changing directory - by default, I think the command prompt opens in the root of the C drive, so you use cd to switch to the build folder that you made earlier.

Will-do.

Edit: I have no idea how to make a debug build.
The enhanced building directions lists no options for making a debug build, and I have no idea where else to look.
You can create a debug build by changing '-DCMAKE_BUILD_TYPE=Release' to '-DCMAKE_BUILD_TYPE=Debug'.
 
Last edited:
Sep 14, 2019 at 3:26 PM
Junior Member
"It's dangerous to go alone!"
Join Date: Dec 22, 2018
Location: Sand Zone Residence
Posts: 32
#87
I don't know what 'cd into it' means
cd = change directory
basically you can write "cd", a space, and then an absolute or a relative directory path and you'll switch your current working directory (cwd) to that directory

examples (assuming you're on Windows):
Code:
cd C:\path\to\CSE2\build - if your current directory is somewhere random
cd build - if you're in a directory that has a child directory called "build", you can list the files and directories of your cwd using the "dir" command
 
Sep 14, 2019 at 3:41 PM
Monster girl enthusiest
"Keep on rollin'!"
Join Date: Sep 22, 2012
Location: Hugging a tentacle monster
Posts: 438
#88
cd = change directory
basically you can write "cd", a space, and then an absolute or a relative directory path and you'll switch your current working directory (cwd) to that directory
Seems a little pointless since you can just use the 'open command window here' feature in windows by holding shift whilst you right click (might also be ctrl, I forgot, I have a registry change that makes it appear by default)
 
Sep 14, 2019 at 3:47 PM
Senior Member
CSE Discord Admin
"This is the greatest handgun ever made! You have to ask yourself, do I feel lucky?"
Join Date: Jan 13, 2016
Location:
Posts: 102
#89
If I remember right, the Developer Command Prompt is different from the regular command prompt, extending the PATH and defining some environment variables. They're needed for CMake to detect the compiler properly.
 
Sep 14, 2019 at 11:13 PM
Neophyte Member
"Fresh from the Bakery"
Join Date: Aug 5, 2019
Location: Hell
Posts: 6
#90
You can create a debug build by changing '-DCMAKE_BUILD_TYPE=Release' to '-DCMAKE_BUILD_TYPE=Debug'.
I assume that the compiling command should be changed to 'cmake --build . --config Debug' too?

edit: compiled with 'cmake --build . --config Debug'.
game now works?

odd.

Seems a little pointless since you can just use the 'open command window here' feature in windows by holding shift whilst you right click (might also be ctrl, I forgot, I have a registry change that makes it appear by default)
I'm pretty unsure, but I think it was grandfathered in from MS-DOS.
 
Last edited:
Sep 15, 2019 at 4:00 AM
Senior Member
CSE Discord Admin
"This is the greatest handgun ever made! You have to ask yourself, do I feel lucky?"
Join Date: Jan 13, 2016
Location:
Posts: 102
#91
Heisenbug... typical. You could replace 'Debug' with 'RelWithDebInfo' too. That makes a release build, but with enough debug info for gdb to be useful.
 
Oct 17, 2019 at 12:07 AM
Senior Member
CSE Discord Admin
"This is the greatest handgun ever made! You have to ask yourself, do I feel lucky?"
Join Date: Jan 13, 2016
Location:
Posts: 102
#92
CSE2 v2.0

Geez, has there really not been a release since May?

Well, here's v2.0. Why v2.0 and not v1.3? Because we've finally reached the second milestone for the project: ASM-accuracy!

The first milestone was making the game completable - playable from beginning to end. Once that was reached back in February, we released v1.0.

But this first release was far from ideal: a lot of the code was visibly the output of a decompiler, and not at all something a normal programmer would write. Take this for example:
Code:
//Get 4 digit number from TSC data
int GetTextScriptNo(int a)
{
    return gTS.data[a + 3] - 48
        + 10 * gTS.data[a + 2] - 480
        + 100 * gTS.data[a + 1] - 4800
        + 1000 * gTS.data[a] - 48000;
}
Do you have any idea what this thing's trying to do? Well, here's the code from v2.0:
Code:
//Get 4 digit number from TSC data
int GetTextScriptNo(int a)
{
    int b = 0;
    b += (gTS.data[a++] - '0') * 1000;
    b += (gTS.data[a++] - '0') * 100;
    b += (gTS.data[a++] - '0') * 10;
    b += gTS.data[a] - '0';
    return b;
}
But, even worse, v1.0 wasn't even trying to be accurate: during the initial decompilation process, me and Cucky ported each part of the engine to SDL2. While this was nice for portability, it kind of goes against the point of a decompilation.

With v2.0, we've killed two birds with one stone! The original DirectDraw/DirectInput/DirectSound/WinAPI code has been restored, and the code in general has been cleaned-up to better match the original source code.

Decompiling the DirectX code is straightforward enough, but some of you might be wondering how exactly we know what the original source code looked like, and what 'ASM accurate' is supposed to mean. Well, it all started with figuring out what compiler Pixel used to create the original EXE...

Many EXE files come with what's known as a "Rich Header", which details various properties of the compilation process, such as how many C or C++ object files were linked, but the part we're interested in is where it says what compiler was used. From this, we learned that it was MSVC .NET 2003.

By using the same compiler as Pixel, we could compile CSE2, and then check if the generated assembly code matches that of the original EXE. If any of the code doesn't match, then we can tweak the C/C++ code until it does match (making it "ASM-accurate").

So that's what I've been up to for the past few months: going over each and every function in the game, and tweaking them to produce the same assembly. Work on this actually started before CSE2 v1.1, but the lack of the original DirectX/WinAPI code caused unfixable code-inaccuracies throughout the entire game, which made a lot of it infeasible at the time.

Some of you might be thinking 'wait, but replacing SDL2 with DirectX/WinAPI means the game can't be compiled for Linux or Mac', and you're right. That's why the SDL2 port was split off to its own subproject: the portable branch.

With this release, CSE2 has been further split into three branches: accurate, portable, and enhanced. The accurate branch focuses on being accurate to the original EXE, down to all the bugs, limitations, and platform-dependencies; the portable branch aims to port the game to other platforms while otherwise keeping the experience as close to the original as possible; and the enhanced branch is the same as it's always been - providing a modified version of the engine with extra features.

Ironically, the accurate branch has become the easiest form of CSE2 for Windows users to compile, since it doesn't depend on any middleware, and it provides a Visual Studio 2017 solution file instead of a CMake file. Fun side-note: there was only one incompatibility stopping this 2004-era code from compiling in modern Visual Studio - DirectInput5 support was dropped in 2008.

Once the migration back to DirectX/WinAPI was complete, I figured I'd re-port the game to SDL2 from scratch. Along the way, I made various improvements to the replacement video, audio, and input backends. The audio and video backends in particular should be substantially faster.

Speaking of the video backend, the portable and enhanced branches now sport multiple video backends: along with a much faster renderer based on SDL2's hardware-accelerated Texture API, there's now a software renderer, a renderer that uses SDL2's software-rendered Surface API (portable branch only), and an OpenGL 3.2 renderer.

On top of all this, CSE2's received a few minor improvements as well: the enhanced branch now allows the user to resize the window, the DoConfig clone has had its broken button mappings fixed (they've always been broken), and Organya should no longer miss beats in the portable/enhanced branches, now that it's been synchronised with the audio callback routine.

Here are the GitHub releases:
CSE2 - Accurate
CSE2 - Portable
CSE2 - Enhanced

I guess this begs the question of what the next milestone is. Well, there are a few things I'd like to see done: for one, producing the exact same EXE would be nice, but right now global variable arrangement and stack frame sorting issues are stopping that. It would also be good to document the game's code more thoroughly - Gabe's been doing a good job of that lately. Then there's the possibility of making the enhanced branch more modder-friendly - maybe add some common community-made TSC commands or hackinator patches. I guess we'll just have to wait and see.
 
Last edited:
Oct 17, 2019 at 1:58 AM
Rosa Online
Pokemon Master
"Life begins and ends with Nu."
Join Date: Jun 27, 2013
Location: Aspertia, Unova
Posts: 2078
Age: 24
#93
maybe add some common community-made TSC commands or hackinator patches.
I would love to see <MS4, <MIM, <PHY, <BUY, and <VAR in CSE2. They're the most go-to custom commands a mod could ever use, and could definitely help benefit CSE2 modding.
 
Top