No announcement yet.

Taking it up

  • Filter
  • Time
  • Show
Clear All
new posts

  • Taking it up

    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?


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


    • #3
      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


      • #4
        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


        • #5
          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.


          • #6
            Good luck with the project. You'll need it. And patience, a whole lot of it.
            Any society that would give up a little liberty to gain a little security will deserve neither and lose both.

            Petrell's Domain Webmaster


            • #7
              What happened, no news? :O


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


                • #9
                  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.


                  • #10
                    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..

                    And a little picture as proof of my efforts