[Announce] PosChengband 1.0.0

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Darin
    Apprentice
    • Jun 2010
    • 53

    #61
    I downloaded and compiled and it works fine now. Thanks!

    Comment

    • AnonymousHero
      Veteran
      • Jun 2007
      • 1393

      #62
      I was contemplating patching some of the printf/64bit-related stuff and noticed that there's a lot of "#ifdef JP" preprocessor stuff which complicates things... @Chris: Are you actually intending to support JP or would it be OK to just remove it?

      Comment

      • chris
        PosChengband Maintainer
        • Jan 2008
        • 702

        #63
        Originally posted by AnonymousHero
        I was contemplating patching some of the printf/64bit-related stuff and noticed that there's a lot of "#ifdef JP" preprocessor stuff which complicates things... @Chris: Are you actually intending to support JP or would it be OK to just remove it?
        I've begun removing the Japanese support since, as you noticed, it really messes up the code base.

        Also, I did roll thru the code base replacing %ld with %d when used with 32 bit variables. When using %ld with longs, I changed it to %d with ints. Clearly the code was old enough that it was written at a time when ints where 16-bits so that a 32-bit variable required %ld. Now ints are 32-bits and %ld requires a 64-bit variable for 64-bit compiles. If you find things that are incorrect in the 1.0.5 codebase, can you let me know? Thanks.

        Comment

        • AnonymousHero
          Veteran
          • Jun 2007
          • 1393

          #64
          Originally posted by chris
          I've begun removing the Japanese support since, as you noticed, it really messes up the code base.

          Also, I did roll thru the code base replacing %ld with %d when used with 32 bit variables. When using %ld with longs, I changed it to %d with ints. Clearly the code was old enough that it was written at a time when ints where 16-bits so that a 32-bit variable required %ld. Now ints are 32-bits and %ld requires a 64-bit variable for 64-bit compiles. If you find things that are incorrect in the 1.0.5 codebase, can you let me know? Thanks.
          There are definitely issues with format strings. (The basic issue is essentially impossible to fix without the use of format string macros if you want to be able to compile on both 32-bit and 64-bit.)

          Do you have a repository (git, hg, whatever) somewhere which we can submit patches against?

          Comment

          • chris
            PosChengband Maintainer
            • Jan 2008
            • 702

            #65
            Originally posted by AnonymousHero
            Yeah, this is really an annoying part of the C89 standard printf(). The only really portable way to get this working properly (without always casting) on 32 and 64 bit is to use format string defines, so something like:

            Code:
            #ifdef ON_64_BIT_PLATFORM
            #define FMTs32 "%d"
            #define FMTu32 "%u"
            #else
            #define FMTs32 "%ld"
            #define FMTu32 "%lu"
            #endif
            and then use them as follows:

            Code:
                 int32_t foo = 123;
                 printf("something " FMTs32 " something something.", x);
            (note that int32_t is also C99.)

            The only other way is simply using "int" everywhere, but that may not be sufficient on all compilers/platforms.
            But isn't this incorrect?
            Code:
                int32_t foo = 123;
                printf("%d", foo);
            works just fine for both 32 bit and 64 bit compiles. Or am I missing something?

            Comment

            • AnonymousHero
              Veteran
              • Jun 2007
              • 1393

              #66
              Originally posted by chris
              But isn't this incorrect?
              Code:
                  int32_t foo = 123;
                  printf("%d", foo);
              works just fine for both 32 bit and 64 bit compiles. Or am I missing something?
              I haven't look at the actual code yet, but there seems to be overflow when displaying negative numbers in the stat display (both for EXP and HP).

              Even if it may work in practice, "%d" is not guaranteed to work for int32_t, only "int". You need to use

              [code]
              printf(PRId32, foo);
              [code]

              to be compliant with the standard.

              Comment

              • chris
                PosChengband Maintainer
                • Jan 2008
                • 702

                #67
                Originally posted by AnonymousHero
                I haven't look at the actual code yet, but there seems to be overflow when displaying negative numbers in the stat display (both for EXP and HP).

                Even if it may work in practice, "%d" is not guaranteed to work for int32_t, only "int". You need to use

                [code]
                printf(PRId32, foo);
                [code]

                to be compliant with the standard.
                Agreed. I was just pointing out that using "%ld" on an known 32 bit int was unnecessary for 32 bit compiles and that the current printf code will work for both compiles, while is obviously bound to break in the future, and is also obviously not the ideal solution.

                I'm not sure about the XP, HP issue. Can you post a screen dump? The code is not using printf for these fields, but rather Angband's hand-coded printf substitute: format.

                Comment

                • AnonymousHero
                  Veteran
                  • Jun 2007
                  • 1393

                  #68
                  Originally posted by chris
                  I'm not sure about the XP, HP issue. Can you post a screen dump? The code is not using printf for these fields, but rather Angband's hand-coded printf substitute: format.
                  Don't have a screenshot at hand, but it should be pretty easy to recreate on a 64-bit compile: Enable the "exp_need" option and level up. This causes a very long number to be displayed -- in fact it "spills" into the column which is supposed to be the gap between stats and the dungeon/map.

                  Anyway, I'm sure I can fix these pretty easily myself if you have a repository somewhere that I can base my work on....

                  Comment

                  • chris
                    PosChengband Maintainer
                    • Jan 2008
                    • 702

                    #69
                    Originally posted by AnonymousHero
                    Don't have a screenshot at hand, but it should be pretty easy to recreate on a 64-bit compile: Enable the "exp_need" option and level up. This causes a very long number to be displayed -- in fact it "spills" into the column which is supposed to be the gap between stats and the dungeon/map.

                    Anyway, I'm sure I can fix these pretty easily myself if you have a repository somewhere that I can base my work on....
                    Oh, OK. I thought you meant the experience field on the character dump. The one you are referring to is
                    Code:
                    static void prt_exp(void)
                    in xtra1.c and it looks like I missed this one! (I know why now ... I searched globally for %ld and this one has %8ld ... sigh):
                    Code:
                    (void)sprintf(out_val, "%8ld", exp_requirement(p_ptr->lev) - p_ptr->exp);
                    If you replace the ld with d in this routine, you should work. exp_requirement returns an int and p_ptr->exp is a s32b (which is also an int).

                    I guess I'll do another regexp search through the code to see what else I find. There are a lot of printf's in the code (thousands!) and it would take a long time to change them all. Are you sure you want to do this?

                    Aside: I looked thru the format() code and it ultimately ends up calling sprintf and otherwise seems to be OK.

                    EDIT: There are ~4,100 format strings in the code base. Also, one needs to be able to handle fixed width fields. There are an awful lot of "%4d" and the like ...
                    Last edited by chris; February 9, 2013, 20:47.

                    Comment

                    • chris
                      PosChengband Maintainer
                      • Jan 2008
                      • 702

                      #70
                      Originally posted by AnonymousHero
                      Anyway, I'm sure I can fix these pretty easily myself if you have a repository somewhere that I can base my work on....
                      I think I have them all this time. I uploaded (1.0.6) source code here. The only changes should be changes to format strings for 64-bit compiles so I did not upload a Windows binary. Next release will be 1.0.7.

                      I don't have a repository on the web at the moment and am resisting putting one up. I used Google Code in the past and its amazing how often it is down and how fantastically slow it can get. If people are interested in long term collaboration on features and what not, I can put one up.

                      Comment

                      • AnonymousHero
                        Veteran
                        • Jun 2007
                        • 1393

                        #71
                        Originally posted by chris
                        EDIT: There are ~4,100 format strings in the code base. Also, one needs to be able to handle fixed width fields. There are an awful lot of "%4d" and the like ...
                        Yay C!

                        (Filler for anti-spam filter.)

                        Comment

                        • AnonymousHero
                          Veteran
                          • Jun 2007
                          • 1393

                          #72
                          Originally posted by chris
                          I don't have a repository on the web at the moment and am resisting putting one up. I used Google Code in the past and its amazing how often it is down and how fantastically slow it can get. If people are interested in long term collaboration on features and what not, I can put one up.
                          I'm guessing you used Subversion?

                          If so, I'd really recommend that you use git instead. When using git you don't really need the repository servers to be up all the time (or even much of the time for that matter). Having said that, I think github.com is pretty dang reliable. There's also bitbucket.org. (You can even have the code hosted in both places -- git makes this pretty easy too.)

                          Comment

                          • chris
                            PosChengband Maintainer
                            • Jan 2008
                            • 702

                            #73
                            1.0.7 is available in the usual place:

                            * Fixed a nasty bug for Shadow-Fairy light vulnerability. Thanks to r@ss.com for pointing this out.
                            * Added Hydras as a player monster race just so this release would have some heft. Hydras can get up to 5 helmet and amulet equipment slots, and up to 11 attacks per round. Getting enough speed for the endgame might be problematic, though. The boss is The Lernean Hydra and the reward was suggested by Djabanete a long time ago.

                            Comment

                            • chris
                              PosChengband Maintainer
                              • Jan 2008
                              • 702

                              #74
                              1.0.8 is available here

                              * Capture Balls should now be working. Note: Capture Balls go in your shield slot, so if you play a monster race that cannot use shields, then you cannot use Capture Balls either.

                              * Rebalanced the Hydra monster race.

                              * Added a new monster race: The Leprechaun. Leprechauns start the game with a pot of gold, possess the luck of the Irish, are fast and stealthy. Many of their powers are influenced by how much gold they have on hand. But they are rather small and weak. If the leprechaun does not wield a normal weapon, then they have low damage innate attacks that pilfer items and gold from their foes.

                              Comment

                              • buzzkill
                                Prophet
                                • May 2008
                                • 2939

                                #75
                                Ah, they're after me lucky charms. Sounds awesome!
                                Attached Files
                                www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
                                My banding life on Buzzkill's ladder.

                                Comment

                                Working...
                                😀
                                😂
                                🥰
                                😘
                                🤢
                                😎
                                😞
                                😡
                                👍
                                👎