Taking it up

[Gibbon]

So I've been using the 2011 build for some time now and I've seen that development is basically dead (no build in 6 years). Since it's a great game, I've decided to take up the challenge of rebuilding it for 64bit using MingW on Windows and of course GNU/Linux.

What I will do:

1. Rip out the MSVC projects and use CMake
2. Link it with 2017 versions of jpeg, zlib etc.. (all compiled for 64bit)

Naturally it will take a while since it's quite a mess (I'm a developer in my day job) so I'll probably be cleaning it a bit also (force of habit )

One question (if anyone knows): Where is the absolute latest code kept? The svn repo here or are any of the Github mirrors more up-to-date?


-G

[vamp07]

I think it is awesome that some of us are still interested in this game. Put me down to help test.

[Gibbon]

So I decided instead to just use codeblocks for Windows builds and I've converted all of the ancient MSVC++6 projects to .cbp files. I've built x64 versions of all the .dll's and created static .a library files from them for Mingw to use during linking.

Though I had to change a few things:

1. ctp2_config.h was awful, if you defined any of the MSVC things, it fails (obviously). So I took out the preprocessor define for _MSC_VER around the config_win32.h and just left it as a normal include, otherwise if you defined it, templates would fail to compile and we don't need these hacks for GCC anyway.
2. ctp2_inttypes.h was changed also to define the HAVE_STDINT_H and again I removed the MSVC specific int typedefs, we can use the standard ones or the ones from stdint (which is in the C std library).

My latest fun: ..\gs\gameobj/Advances.h:59:10: fatal error: AdvanceRecord.h: No such file or directory

Tracking down a mythical file

[Gibbon]

The cause of these errors is flex and yacc (byacc lex) not executing correctly. It was being given the '-o' flag instead of '-l' in modern versions so these files for dbgen were not run and thus dbgen never generated the Record files. I actually had gotten it to nearly compile on a raspberry pi just so I could get these files generated and analyze why on Windows it wasn't.

So I'll fix the project for Windows and carry on

[Gibbon]

ctp2_code\\gs\\slic\\slic.y:141.48-49: $2 of `typedef' has no declared type

I get hundreds of these for every single .y (bison files) on Windows. GNU/Linux is ok and generates everything fine, which is strange. Now I'm not a bison expert so what I am doing is generating the .cc files for each bison file on GNU/Linux and then copying them to Windows and removing the lex and bison files so we only compile the C++ stuff. It's working and I've gotten half of the source to compile.

[Petrell]

Good luck with the project. You'll need it. And patience, a whole lot of it.

[Erenussocrates]

What happened, no news? :O

[cue]

How about a money price for bug fixes?
Please dont kill this game.

[Gibbon]

Don't worry, I'm still going

Basically, the Linux version is an absolute PITA to build on my compiler (GCC7) so I am only working on the Windows version. I guess since it's going to be the system with the widest userbase. I've gotten most of the DLL's to build in a 64bit environment. But there are thousands of lines which require a very specific setup. So it's taking quite a while.

[Gibbon]

Maybe I should go back to providing updates..

1. I finalized the setup for VS Community Edition. All new flex, byson, libs and dependencies are automatically done when building. Only the ctp2db.exe needs to be built independently.
2. I actually decided to stay with a 32bit build a few weeks ago because the pointers are an absolute no go for 64bit. Fixed a few things with it but it really needs a total overhaul to correct some of the assumptions with memory handling and pointers. More than a single person can handle.
3. Around 35% of the code compiles without a single issue on C++11 settings.

Slowly it's getting there. Just some templates and classes I need to rewrite because it's old-style definitions.. I'm amazed it even compiled in 2011 to be honest..

[menocheck]

Good to know that you're still alive

I would also like to help.
I am running a Linux setup and tried to compile this project during the last few weeks. And it is a pain like you said. However i did manage to get it to compile so i am now stuck with the linker errors. And in the current form it probably won't run on linux anyway.

I think i will throw out the Automake stuff as it is complex and littered all over the place and try to port it to meson.

[Gibbon]

Nice, thanks for helping!

That was my main issue also, all the ugly automake stuff that had to be modified etc.. automake in general causes more problems then it solves.

Windows also has it's issues. I doubt anyone has touched the windows code for at least 10 years. It's littered with illegal C++ such as deriving virtual functions when the functions in those classes are not derived. The code is set into DX7 (using dinput.lib instead of dinput8.lib) and code that doesn't exist.. did that 'buttonbank.cpp' catch you also?

At my current point, it takes about 40 minuts to compile, so every error fixed is basically an hour gone.

Someone compiled updated libraries for all the dependencies for Windows too. But they don't know about VS obviously because they were created by old versions, meaning the linker vomits because of byte mismatch.. so now I'm compiling freetype, zlib.. such fun

I guess when we've acheived the good compilation, we should somehow sync both of our changes and try and get it back into the svn repo.. as per the licence.

[Gibbon]

Ok, so finally it's here. I've gotten a 32bit compiled ctp2r.exe.

However there are a few issues and shortcuts I've had to do:

1. Disable DirectInput - it is using a DX7 version and is not compatible with the W10 SDK. Porting to CoCreateInstance will be needed.
2. Whatever version of freetype the .lib is, it is not possible to substitute with a newer version. Mine are 700kb and this one is 192kb. The copyright is from 1999 so... changes will be needed for the fonts and graphics handling to use a newer freetype api. For now I've disabled the byte checking so it uses this lib.
3. The Windows version still requires the Miles library. There is a stub but not distributable dll to use.
4. The exe doesn't actually start. You get the 800x600 window popup and then, memory failure.

A lot of debugging will be needed. Probably it's a good idea to somehow get this uploaded to the svn.

[menocheck]

Cool, i have also managed to get a complete binary. But i stayed with 64bit, guess i will regret that soon.

Wow that are some compile times. It takes me only 2 minutes, maybe i am missing something?

My issues where:

1. Some include directives had wrong case in the header-filename.
2. freetype: Ran into the same, but since it's open source i download the last version of the freetype 1 code (yes that from 2000) and it actually complied on first try. But we should definitely update to freetype2 later on.
3. To be honest i have no idea how the DirectX Stuff is handled on linux. There is SDL but i don't think that's everything/complete.
4. Well the binary crashes immediately. You lucky boy got a window

Yes i think we should merge our changes into svn asap. I already got an account from marc and will wrap some changes up that i think are easy/safe.

[Gibbon]

I'll try that freetype1 suggestion. Never used anything else but freetype2.

In general VS is quite slow to compile, cl.exe is a pretty good compiler nowadays but it's speed is not amazing. From what I've seen, there are preprocessor definitions so all the SDL stuff is only from the Linux side, which is really confusing to me because it would work just fine on Windows too.

My guess is the original people doing this just did it for Linux and didn't bother with Windows stuff. It's completely separated by MSVC and _WIN32 defines.

I will clean up my development folder so that I can prepare a diff.