Loading ...
Sorry, an error occurred while loading the content.
 

Re: Java Gladiator

Expand Messages
  • Sean Ford
    I solved that problem all ready :) I wrote a C utility that converts PIX files to targa (TGA) graphic files. You can use any graphics program to convert the
    Message 1 of 9 , Feb 17, 2008
      I solved that problem all ready :)

      I wrote a C utility that converts PIX files to targa (TGA) graphic
      files. You can use any graphics program to convert the tga files to
      just about any other format.

      If you are interested in it, its located in the Openglad-e SVN
      repository. SVN instructions can be found at:
      http://sourceforge.net/svn/?group_id=50083

      The C program is located in openglad-e/trunk/util/convert.c. All the
      targa graphics are located in openglad-e/trunk/pix. Note though that
      all the graphics have an extra row of pixels at the top. We were going
      to use this row to store frame data for the animations (such as the
      number of frames in the animation), and all the color cycling data.

      Sean

      --- In gladiator@yahoogroups.com, "alternate_dph" <alternate_dph@...>
      wrote:
      >
      > I ran into a small problem trying to work on the graphics, mainly
      > figuring out how the animation works in the game. Plus I got to find
      > a program to convert pix files to gif files for java to handle it.
      > I'm hoping to have something ready by February 5.
      >
    • alternate_dph
      There are a couple of issues I ran into. 1)I couldn t find the code in the code where it changes a character s color to match a specific team. That s a very
      Message 2 of 9 , Feb 17, 2008
        There are a couple of issues I ran into.

        1)I couldn't find the code in the code where it changes a character's
        color to match a specific team. That's a very big issue. If I have
        the image in a certain way to be able to change color of the
        character, . . that can get real fun.

        2)I can't seem to find the code that lets a character walk in any
        direction. Without that, I'm at a little loss.

        3)I ran into a constant problem of reading strings from binary files
        from Java. Problem is there is no symmetry in the commands.
        Literally, Java has one command to write strings to binary files, but
        the only way to read strings in is 1 character at a time.

        --- In gladiator@yahoogroups.com, "Sean Ford" <aglswapbuffers@...> wrote:
        >
        > I solved that problem all ready :)
        >
        > I wrote a C utility that converts PIX files to targa (TGA) graphic
        > files. You can use any graphics program to convert the tga files to
        > just about any other format.
        >
        > If you are interested in it, its located in the Openglad-e SVN
        > repository. SVN instructions can be found at:
        > http://sourceforge.net/svn/?group_id=50083
        >
        > The C program is located in openglad-e/trunk/util/convert.c. All the
        > targa graphics are located in openglad-e/trunk/pix. Note though that
        > all the graphics have an extra row of pixels at the top. We were going
        > to use this row to store frame data for the animations (such as the
        > number of frames in the animation), and all the color cycling data.
        >
        > Sean
        >
        > --- In gladiator@yahoogroups.com, "alternate_dph" <alternate_dph@>
        > wrote:
        > >
        > > I ran into a small problem trying to work on the graphics, mainly
        > > figuring out how the animation works in the game. Plus I got to find
        > > a program to convert pix files to gif files for java to handle it.
        > > I'm hoping to have something ready by February 5.
        > >
        >
      • Sean Ford
        1) Gladiator uses a 255 color palette so each color can be addressed as an individual byte. In the PIX files, the team color is defined as any color above
        Message 3 of 9 , Feb 18, 2008
          1)
          Gladiator uses a 255 color palette so each color can be addressed as
          an individual byte. In the PIX files, the team color is defined as any
          color above color index 247 (colors 248-255). Gladiator draws each
          graphic pixel-by-pixel. When it attempts to draw a pixel with a color
          >247, it will take the team number and use it remap that pixel to the
          proper team color.

          Openglad is pretty much a direct port and uses the same method. If you
          look at the Openglad source code, the walker.cpp source file draws a
          single character to the screen at line 982 (continuing for about 50
          lines). You will notice that it calls video::walkputbuffer(). One of
          the arguments is query_team_color(). The walkputbuffer() function is
          located at video.cpp:723. The relevant team color line is:
          if(curcolor > (unsigned char) 247)
          curcolor = (unsigned char) (teamcolor+(255-curcolor));

          Openglad-e uses a little different method. In order to effectively use
          OpenGL, I can't draw images pixel-by-pixel. So I handle the team
          colors when I load the image. On loading, I traverse the image
          pixel-by-pixel and will replace each generic team color with the
          correct color according to the team of the character I am loading the
          image for.

          2)
          The character walk code is handled in walker::walkstep(). It is
          essentially an switch statement that changes the walk amount according
          to which direction it is facing.

          The pixien class (parent of walker) handles the current animation
          frame in set_frame(). set_frame() will update the bmp pointer to point
          to the correct frame. Walker will then call set_frame whenever it
          needs a new frame such as when the user changes directions or does the
          walk animation.

          3)
          Java is not very good in handling binary data :( I recently had to
          process fairly complicated binary files in Java for my research lab. I
          wrote an object that extended ByteArrayInputStream and added methods
          like readUInt32, readSInt16, readNullTerminatedString(), etc that let
          me grab all the data I needed easily. Those functions all read the
          byte array a single byte at a time, but at least that was all abstracted.

          Sean

          --- In gladiator@yahoogroups.com, "alternate_dph" <alternate_dph@...>
          wrote:
          >
          > There are a couple of issues I ran into.
          >
          > 1)I couldn't find the code in the code where it changes a character's
          > color to match a specific team. That's a very big issue. If I have
          > the image in a certain way to be able to change color of the
          > character, . . that can get real fun.
          >
          > 2)I can't seem to find the code that lets a character walk in any
          > direction. Without that, I'm at a little loss.
          >
          > 3)I ran into a constant problem of reading strings from binary files
          > from Java. Problem is there is no symmetry in the commands.
          > Literally, Java has one command to write strings to binary files, but
          > the only way to read strings in is 1 character at a time.
          >
          > --- In gladiator@yahoogroups.com, "Sean Ford" <aglswapbuffers@> wrote:
          > >
          > > I solved that problem all ready :)
          > >
          > > I wrote a C utility that converts PIX files to targa (TGA) graphic
          > > files. You can use any graphics program to convert the tga files to
          > > just about any other format.
          > >
          > > If you are interested in it, its located in the Openglad-e SVN
          > > repository. SVN instructions can be found at:
          > > http://sourceforge.net/svn/?group_id=50083
          > >
          > > The C program is located in openglad-e/trunk/util/convert.c. All the
          > > targa graphics are located in openglad-e/trunk/pix. Note though that
          > > all the graphics have an extra row of pixels at the top. We were going
          > > to use this row to store frame data for the animations (such as the
          > > number of frames in the animation), and all the color cycling data.
          > >
          > > Sean
          > >
          > > --- In gladiator@yahoogroups.com, "alternate_dph" <alternate_dph@>
          > > wrote:
          > > >
          > > > I ran into a small problem trying to work on the graphics, mainly
          > > > figuring out how the animation works in the game. Plus I got to
          find
          > > > a program to convert pix files to gif files for java to handle it.
          > > > I'm hoping to have something ready by February 5.
          > > >
          > >
          >
        • alternate_dph
          Thanks. That solves a lot of my problems. ... as an individual byte. In the PIX files, the team color is defined as any color above color index 247 (colors
          Message 4 of 9 , Feb 18, 2008
            Thanks. That solves a lot of my problems.

            --- In gladiator@yahoogroups.com, "Sean Ford" <aglswapbuffers@...> wrote:
            >
            > 1) Gladiator uses a 255 color palette so each color can be addressed
            as an individual byte. In the PIX files, the team color is defined as
            any color above color index 247 (colors 248-255). Gladiator draws each
            graphic pixel-by-pixel. When it attempts to draw a pixel with a color
            247, it will take the team number and use it remap that pixel to the
            proper team color.

            I was afraid of that. I've seen a lot of examples that create images
            from arrays, an approach that looked a lot more involved than I cared for.

            > Openglad is pretty much a direct port and uses the same method. If
            you look at the Openglad source code, the walker.cpp source file draws
            a single character to the screen at line 982 (continuing for about 50
            lines). You will notice that it calls video::walkputbuffer(). One of
            the arguments is query_team_color(). The walkputbuffer() function is
            located at video.cpp:723. The relevant team color line is:
            if(curcolor > (unsigned char) 247) curcolor = (unsigned char)
            (teamcolor+(255-curcolor));

            So that's how it is done.

            > Openglad-e uses a little different method. In order to effectively
            use OpenGL, I can't draw images pixel-by-pixel. So I handle the team
            colors when I load the image. On loading, I traverse the image
            pixel-by-pixel and will replace each generic team color with the
            correct color according to the team of the character I am loading the
            image for.

            Oh joy. *stratches head* Keeping memory usage might be tricky then.
            Keeping a single generic version might be cheapier on memory
            initially, but the potential slow down for creating new specific
            images on the fly as well storing multiple versions of the same image
            in memory doesn't sound pleasant.

            > 2) The character walk code is handled in walker::walkstep(). It is
            essentially an switch statement that changes the walk amount
            according to which direction it is facing.

            Ahh.

            > The pixien class (parent of walker) handles the current animation
            frame in set_frame(). set_frame() will update the bmp pointer to
            point to the correct frame. Walker will then call set_frame whenever
            it needs a new frame such as when the user changes directions or does
            the walk animation.

            Yea, that solves one of my problems. I figured how to load the images
            but figuring out which 'part' of the image corresponded to which state
            was getting perplexing.

            > 3)
            > Java is not very good in handling binary data :( I recently had to
            process fairly complicated binary files in Java for my research lab.
            I wrote an object that extended ByteArrayInputStream and added methods
            > like readUInt32, readSInt16, readNullTerminatedString(), etc that
            let me grab all the data I needed easily. Those functions all read the
            byte array a single byte at a time, but at least that was all
            abstracted.

            I found a set of code that supposedly is a workaround for not being
            able to read strings in as a string. Reading strings in is a big deal
            for multiple reasons. The obvious one is the saved game file. But
            there are other advantages. I plan on using my old binary file format
            I created to read in all the map tiles in through a loop. Just read 1
            line of info about the map tile, pull out the map tile name, and read
            the map tile in. Repeat process for every map tile. Quite efficient.
            Only problem was I never figured out a way to systematically read the
            smoother function as data. If anyone can figure out a way to rewrite
            the smoother function rules so that they can be read in through a
            binary file, I would be more than impressed.

            Thanks a bunch, Sean.
          Your message has been successfully submitted and would be delivered to recipients shortly.