Announcement

Collapse
No announcement yet.

COMPILE: Linux Port

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    Originally posted by btb
    So, I'd like to fix the filename case, but we need to decide on a consistent standard. I think that going with Activision's original intent is the simplest.

    It looks like most of the time activision intended to use mixed case (FileName.cpp, etc), but then they got lazy.

    Some modules however, it seems they intended to use lowercase only - ui/aui_*, for example.
    Hi Brad,

    Yea, this should be fixed properly. What I have been doing is changing the filenames in code and not renaming the files on disk. So I don't have do cvs delete and cvs add the renamed file (btw, is there a better way to do this?)

    I put a script in the linux dir called fixcase.sh to make this a little easier.

    Although I agree that calling the filename the same as the class it defines is good style.

    Comment


    • #47
      I think that if you have access to the cvs repository, you can just rename the files directly, and then it'll be as if it had always been that way. It's been a long time since I tried anything like that though.

      Comment


      • #48
        Uh oh, I got a problem here...

        in gfx/spritesys/Sprite.cpp there are calls of some dirty MS Function called _msize, which returns the size of the allocated memory to a pointer.

        A search on the internet with "_msize" and "gcc" mainly returned things like this:

        foo = _msize(bar);
        /* not portable to gcc */


        does anybody know how to replace that function? Or else I'll have to figure out, what memory is allocated and somehow store this in a new variable.

        Comment


        • #49
          I saw that too. I _think_ we can get away with using the (unsupported, undocumented, unportable) function malloc_usable_size()

          i.e. just do:
          #ifdef __GNUC__
          # define _msize malloc_usable_size
          #endif

          Comment


          • #50
            for anyone doing some dev work in windows while trying to understand the code, http://unxutils.sourceforge.net/ has win32 ports of most of the good unix commandline tools. And there's a port of GVIM for windows also at vim.org

            Comment


            • #51
              Originally posted by teknomage1
              for anyone doing some dev work in windows while trying to understand the code, http://unxutils.sourceforge.net/ has win32 ports of most of the good unix commandline tools. And there's a port of GVIM for windows also at vim.org
              Erm, this is the linux port thread. Kinda hard to port a game to linux if you're working in windows...Therefore i dont think we need win32 ports of commandline tools or editors. Go post in a windows thread, they might need those tools, or post in this thread and add something constructive.

              I saw that too. I _think_ we can get away with using the (unsupported, undocumented, unportable) function malloc_usable_size()

              i.e. just do:
              #ifdef __GNUC__
              # define _msize malloc_usable_size
              #endif
              So were replacing a dirty win32 hack with a dirty glibc hack
              Anyway, it compiles and we have to test whether this works. (I have a bad feeling, that there we will need some extensive debugging once we get a binary)

              Comment


              • #52
                I realize you're porting it to linux dude. I just didn't realize how far you'd gotten from what I understood it folks were still trying the grok the code...ungrateful..blah.
                -----------------------------------------------------------------
                posted from Gentoo Linux running 2.6.0-test10-mm4

                Comment


                • #53
                  enums

                  This is how I propose we handle enums. Just so we're all on the same page.




                  If you see

                  enum C3DIR {
                  C3DIR_DIRECT = -1,
                  ...
                  };

                  change it to

                  typedef sint32 C3DIR;
                  enum C3DIR_enum {
                  C3DIR_DIRECT = -1,
                  ...
                  };




                  If you see

                  enum C3DIR;

                  change it to

                  typedef sint32 C3DIR;




                  The compiler can promote C3DIR_DIRECT to a sint32 without any trouble.

                  Mike

                  Comment


                  • #54
                    Re: enums

                    Originally posted by closms
                    This is how I propose we handle enums. Just so we're all on the same page.
                    Grrr.. Of course there is a problem with this already. If all enums are now sint32's then operator overloading won't work. ie

                    Player::FindAgreement(const PLAYER_INDEX otherParty)
                    Player::FindAgreement(const AGREEMENT_TYPE agreement)

                    used to work, but now doesn't. I'm going to chnage it to

                    Player::FindAgreementPI(const PLAYER_INDEX otherParty)
                    Player::FindAgreementAT(const AGREEMENT_TYPE agreement)

                    for now. Ideas??

                    Mike

                    Comment


                    • #55
                      I am suddenly missing a file "lin_compat.h". I guess somebody made that file and forgot to add it to the cvs. So if the maker could add that file I would be happy

                      Comment


                      • #56
                        Originally posted by uppi
                        I am suddenly missing a file "lin_compat.h".
                        Done.

                        Comment


                        • #57
                          Anyone else notice that the networking code uses the anet library. And we have a dll but no source. I guess we can cut multiplayer support for now. Any chance we can get this source code or at least a linux .so?

                          Comment


                          • #58
                            Originally posted by closms
                            Anyone else notice that the networking code uses the anet library. And we have a dll but no source. I guess we can cut multiplayer support for now. Any chance we can get this source code or at least a linux .so?
                            Probably it is the same library as used in CTP1 and as there is a linux version of CTP1 there should such a file, but I can remember that we found something about it in the internet maybe but I am not sure the source code was also there.

                            -Martin
                            Civ2 military advisor: "No complaints, Sir!"

                            Comment


                            • #59
                              Originally posted by Martin Gühmann


                              but I can remember that we found something about it in the internet maybe but I am not sure the source code was also there.

                              -Martin

                              Yep. Here it is. Thanks Martin.

                              Comment


                              • #60
                                Wow, it's LGPL even. Of course, normally integration of LGPL software would not be possible, since it's incompatible with the ctp2 license... In this case, though, since it's the same library Activision used originally, we wouldn't be actually creating a "derived work".

                                Comment

                                Working...
                                X