Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Coraline

Members
  • Content count

    1178
  • Joined

  • Last visited

About Coraline

  • Rank
    Senior Member

Recent Profile Visitors

3733 profile views

Single Status Update

See all updates by Coraline

  1. About ROTT textures: I don't know what they are .. BUT.

    You mentioned how to change the drawing routines to handle such a thing.  I advise against that.

     

    DoomLegacy has the R_GenerateTexture function in r_data.c, that gets every texture in the wad, and

    converts it to some format that our drawers can handle.  I suggest you use something similar.

    It gives you the chance to fix other texture problems at the load stage, and keep your drawers simple and running at full speed.

     

    It currently handles some strange wad patches that took advantage of the vanilla doom drawer, but disrupted our new drawers.

    Some wad textures used a patch that was smaller than the texture, which caused segfaults.  These are fixed by R_GenerateTexture.

    Some patches reused patch columns, as an effort to hand compress the patches. That required special handling.

    Multi-patch textures are converted to a single-patch texture, or a picture format.  Those draw much faster.

     

    You could use a similar scheme to intercept these ROTT textures and convert them to one of the formats you can draw.

    The code would take the row-oriented pixels and scatter them to the columns of a patch format.  That would require preallocating the columns according to how many rows there were, and then filling in the data.  If the number of rows exceeds the maximum post length, then must have extra column depth allocated to have multiple posts (extra post headers).

    If there are holes in the patches, then there will be extra posts, extra post headers, and then the columns will have to be packed in a final step.

    That assumes that you prefer patch format for your textures.

     

    If you can draw picture format, then that is easier to generate.  Just preallocate a buffer to the picture size needed, and draw the ROTT texture into the picture buffer.  If there are holes in the ROTT texture, then you need a transparent pixel code.  Any ROTT pixel that hits that transparent code gets changed to some other color.

     

    The R_GenerateTexture function handles the patch format, and has better documentation in that function than I could explain here.  You could probably borrow from it.

     

     

    1. Show previous comments  8 more
    2. wesleyjohnson

      wesleyjohnson

      Each one of the those melt-lines is coming from the end of a ROTT texture draw.

      I suspect it is drawing one column too many.  I can tell by the colors that the melt-line data is not from the texture.

      The FOR loop end test is off by one.

      The doom drawer and the ROTT drawer are using entirely different loop limits, and I cannot tell why.

       

    3. Coraline

      Coraline

      @wesleyjohnson Pushed the new code to Github, which you can see the column code for ROTT was nearly fixed with your previous suggestions: 

       

      https://github.com/3dfxdev/hyper3DGE/blob/3b788058e336335163111a33e1283c8a8a824e81/src/r_doomtex.cc#L332

       

      Not sure what you mean by the FOR loop end test is off by one - by an addition or a subtraction? 

       

      There was something else I was wondering about. In the rottpatch_t struct, the columnofs value is strange [320] - EDGE translates this in its patch code to [1], where this was originally [8] in DOOM. But, still unsure where or why that value is what it is in columnofs. Keep in mind in Rise of the Triad, columnofs was originally called collumnofs:

       

      //normal DOOM patch
      
      typedef struct patch_s
      
      {
      
      // bounding box size
      
      short width;
      
      short height;
      
      // pixels to the left of origin
      
      short leftoffset;
      
      // pixels below the origin
      
      short topoffset;
      
      int columnofs[1]; // only [width] used
      
      }
      
      patch_t;
      
      
      
      //ROTT Patch, notice columnofs is at [320] in ROTT - not sure why that value is even set.
      
      typedef struct rottpatch_s
      
      {
      
      short origsize; // the orig size of "grabbed" gfx
      
      short width; // bounding box size
      
      short height;
      
      short leftoffset; // pixels to the left of origin
      
      short topoffset; // pixels above the origin
      
      unsigned short columnofs[320]; // only [width] used, the [0] is &collumnofs[width]. CA - Renamed from collumnofs to columnofs!
      
      }
      
      rottpatch_t;
    4. wesleyjohnson

      wesleyjohnson

      In that usage it does not matter.  That structure is never allocated statically, so the allocation size is never determined from the array size or the struct size.  There are some conventions that can be followed, and those may make a difference to the compiler, sometimes.

      The [320] is a practical limit as the patch width could hardly be more than 320, as that was the width of the screen.

      In DoomLegacy we declare it as  columnofs[8], but the pic_t data array is declared as  data[0].  It does not matter.

      Some more modern languages have a way to declare a dynamically sized array, but C doesn't.  The compiler and reader are expected to understand that the array size is ignored on a dynamically sized array.  The array size is limited by how much memory got allocated for the struct, and the programmer is responsible for not accessing the array beyond the allocated memory.

       

      About the ROTT column draw.

      Notice in the last screenshot the black column at the end of the "Main Menu".  Notice how it is a different color than the "Main Menu" text.  Notice how it starts at the top of the patch, just like another patch column.  This is due to drawing one too many columns for "Main Menu".

      It looked up a columnof[16] got an offset, and drew the data at that column.  Because the compiler does not know that the patch only had columns 0..15, it does not know that the columnofs[16] is off the end of the array, and the column data is bogus.  That is why it is drawing white and black, and not the colors of the rest of the text.  It also gets a bogus post header with a bogus count, which is why the column goes completely down the screen.

      The problem is that it is drawing one too many columns for the patch.

       

      Possibilities, one of the following is likely:

      1. It got the width wrong for the patch

      2. The patch format requires drawing one less than the patch width, for some reason.

      3. The FOR loop that iterates the width has a messed up test (off by one, otherwise known as the fence post error).

      4. The ROTT drawer is using the wrong variable to count the number of columns.  The number of columns is not always the width of the texture (sometimes the patch is shorter than the texture).

      5. The offset to the table is off by one column width, effectively making it start it address columnofs[1]

       when it is trying to address columnofs[0].  Thus the count against the width would be correct, but it would draw the last column using data past the end of the array.

       

      I would need to look at the "Main Menu" patch, and the texture width, and the number of columns drawn.

      But you can do this faster, just by putting some print stmts in the ROTT column drawer.

      Print the ROTT patch header, and the column index of each column that gets drawn.  Enable this just when the "Main Menu" texture is drawn.  You don't want it for everything, as we want one non-confusing output.  If you can print it once and only once, that will be fine.  If you can print it to a file, then even better.  That will tell us what is going wrong.

       

×