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

3742 profile views
  1. @wesleyjohnson from @Chilly Willy: I do the same thing for Xubuntu, so I would need a bit more info on how you have your setup configured. Also I'm updating the Git shortly with the ROTT fixes. I've learned some interesting information though, which I'll share on your wall in a bit. Still not completed, but it is being attended to, we promise. Gah, great catch! I forget how fun Bots are (used to do Botmatch in my old Blood/Hypertension TC). I will patch it so it only affects the player(s) being displayed currently. I'll probably fix it in a devbuild. @VGA I added your resolution to the possible modes list for SDL2. That'll also be in a devbuild due to be uploaded shortly.
  2. You know, something I just thought of... Is there a function within EPI endianess routines to convert from an Integer to unsigned short? I just realized...if I did that i could technically avoid having ROTT patches in their own struct entirely. . .keep the code tidier by just having everything in the base patch_t structure and that could potentially make it easier to handle those patches.

     

    Also, does EDGE explicitly require a pnames and/or TEXTURE1/2 for textures and patch displays? Since ROTT just displays patches directly, i wonder if even a lone dummy value would work..its either that or i would need to meticulously hand-roll one... I want to say EDGE has that capability but I could be wrong. .

    1. andrewj

      andrewj

      Sometimes a struct like patch_t is used to represent the exact (bit-for-bit) structure of the binary data in a lump or file.  So you cannot change, for example, a short to an int in that structure because the sizes are different (16 vs 32) and it won't read the binary data in the lump properly anymore.

       

      Other structs are used in memory, and it is less important if a field is a short or an int.  EDGE code does not make the distinction between these two usages very clear.  In Eureka and AJBSP, the file w_rawdef.h contains the structs for on-disk binary data, and they are only used to read/write the binary lumps, other structs are used for in-memory version (of a linedef, sector, etc).

       

      For example, raw_linedef_t is a struct for the raw (on-disk) representation of a DOOM linedef, and raw_hexen_linedef_t is the variant use in the Hexen map format.  These are converted to a single in-memory struct "linedef_t" by code which reads the LINEDEFS lump in maps.  This linedef_t has enough fields for both the DOOM version and the HEXEN version.  The types of fields can be "wider" too, e.g. the "flags" field in linedef_t is an "int" (32 bits) whereas the on-disk structure uses a 16-bit value (a "short").

       

      The EPI endianness conversion functions need to be a specific size, like 16 bits, since they need to work on the raw representation of binary data.  If you are reading the value into a different struct, you can have a wider type (like an "int"), but you don't need any extra endianness functions, in C and C++ integers of different widths are automatically converted.

       

      (will answer the other question later)

  3. The translevel/hdr_size stuff is safe to be completely removed, I am intentionally leaving out the translevel stuff and using the single struct to handle all cases of it; we do this in the column drawing code anyway. In r_image, I restored the rpat->origsize buffer and got rid of that custom rolled one so it's read like the other EPI_LE_S16(pat->[]) values.
  4. We did at one point. But it got sidetracked as bigger features that were in higher demand were done first (OpenAL is a big one, finishing up polyobjects, UDMF, COAL stuff, ROTT). Maybe we will revisit it sometime, maybe not, but the important thing there is that we get all of those issues done first. We know that UDMF is in demand for better map support, things like OpenAL are necessary to replace horrid SDL2 audio and all the features that have been long requested, etc. Split screen though needs to be addressed first however, the input reworking is sort of a big deal right now as major parts will need to be added onto for configurable controls across both players. Which, once splitscreen is done, will pave the way for at the very least LAN play across a network. Haven't looked into it heavily as it was def in a state of flux, having been reworked a handful of times across development of the engine.
  5. That's precisely why I haven't had the team take on that solution - all of the engines I've seen that moved to such a model did it very early in their development cycles. It would be too daunting for the team to rework EDGE for such a thing when there's more practical work that needs attention. If we had someone skilled in such a task and had a coordinated way of going about it - fine, but we aren't in that position to allocate resources in a huge way. It is an issue we will eventually address (as its even listed in our Git issues, so we talk about it from time to time), but will probably end up going with something like the first suggestion if/when we get around to it.
  6. Thank you Fanatic! Very honored to hear this from you! PS: QDoom 1.01 works great ;) Also, we have just released EDGE-2.1.0-RC1.5 via SourceForge. This is a very small bugfix that makes screenshots work in both JPEG/PNG formats again. It also contains slight additions for ROTT support and a few QDOOM 1.01 fixups ;-)
  7. Found an additional serious bug: PNG screenshots are broken (due to our new image backend code) - we are working on a fix. Sorry for the inconvenience! FIXED IN RC1.5!
  8. 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.

       

  9. The resolution changes depending on what your screemode is (window or full). You can also explicitly set EDGE to start up with the resolution of your choice. I'll add that into our possible screenmodes enum just in case though! @VGA From the Readme: Try running EDGE with those command-line parameters and let me know if it works out.
  10. @wesleyjohnsonI was waiting until we released RC1 (today) before I switched us back to the Git versioning system. That way RC1 will be uniquely identified in this point of history without tags or commits. I'll check out your PM later today. Without further ado: EDGE 2.1.0-RC-1 has been released via SourceForge! Binaries for Linux are coming later as I didn't have time to compile and upload before work! https://sourceforge.net/projects/edge2/files/3DGE binaries/2.1/2.1.0/RC-1/ There is a huge list of changes between 2.1.0-Test3/2.0.4 and 2.1.0-RC1, so make sure to check out the CHANGELOG. Downloads are available currently for 32-bit and 64-bit Windows platforms. This release candidate is one of many that we are putting out before 2.1.0 Final, in the hopes that we can catch bugs and serious issues before the final launch. Attached is a listing of the currently known bugs in the engine - before you ask for help, please look here first.
  11. Build LOG for EDGE

    System: Slackware 14.2, Linux 4.4.88
    GCC 5.5.0

    # These are the steps that I took.
    # These should be listed in a Linux specific file in your build docs.

    >> mkdir /usr/local/src/game/edge
    >> cd /usr/local/src/game/edge
    >> unzip <source_zip_file>
    >> mkdir build
    >> cd build
    >> cmake ../hyper3DGE-master

    # CMake accepted what I have for libraries.
    # CMake created a Makefile

    >> make

    fatal: not a git repository
    # ignored this error and continued on

    # Compiled successfully

    # Did not find instructions on how to install or where it would be installed if I let the Makefile do the install.

    # Install to /usr/local
    # Requires root permissions to make directories.
    >> make install
    # This builds: EDGE, lzma, zdbsp, zipdir, edge_epk
    # Installed: /usr/local/share/games/doom/edge.epk   (13 MB file)

    # Installation was not complete.
    # I manually copied binary to /usr/local/games, root permissions needed.
    >> cp EDGE /usr/local/games


    # attempted to run edge, as user
    >> /usr/local/games/EDGE
    # Many messages, could not find an IWAD

    # attempted to run edge, as user
    >> /usr/local/games/EDGE -iwad gaming/doom/iwads/id/doom2.wad
    # Many messages, could not find edge.epk
    # This had been installed by the Makefile to
    #   /usr/local/share/games/doom/edge.epk








    # The available targets for the Makefile
    # These need to be in an install file somewhere !!

    # Compile
    >> make all

    # Remove objects
    >> make clean

    # List the install components
    >> make  list_install_components
    # Available install components are : "Game resources"

    # Install to /usr/local
    # Requires root permissions to make directories.
    >> make install
    # This builds: EDGE, lzma, zdbsp, zipdir, edge_epk
    # Installed: /usr/local/share/games/doom/edge.epk   (13 MB file)

    # Install a stripped version
    >> make install/strip

    # Install to the local directory
    >> make install/local
    # Do not know what that did ???



    # These may be used internally by the CMake system, but it is hard to tell.

    # Rebuild the CMake cache
    >> make rebuild_cache

    # Edit the CMake cache
    >> make edit_cache



    Wesley Johnson
    DoomLegacy Development Team
     

  12. 3DGE Library Versions (checking requirements on Linux system)

    NOTE: At least 1 bug in the lib_versions.md file that you should fix

    ( physfs version).

     

        Please note that all libraries **must be statically linked** to the EXE (except for SDL2 on Win32).
          -- WHY, on Linux too ??

    ----------
    System: Slackware 14.2,  Linux 4.4.88

    Upgraded to the latest packages of the the Slackware site,  9/30/2018.

    Did you list the library versions according to the features you need,
    or did you just list whatever you had on the system you were
    developing on ?

    I suspect that these are not actually the required versions.

    Requirement:    /libogg-1.3.2
    Have: libogg-1.3.2
          liboggz-1.1.1

    Requirement:    /libvorbis-1.3.5
    Have: libvorbis-1.3.6
          libvorbis-tools-1.4.0

    Requirement:    /physfs 3.1
    PROBLEM>>> search shows latest version is 3.0.1
    Have: physfs-3.0.1

    Requirement:    /SDL2 (2.0.5, upgraded from 2.0.3)
    Have: SDL2-2.0.5
          SDL2_gfx-1.0.3
          SDL2_image-2.0.1
          SDL2_mixer-2.0.1
          SDL2_ttf-2.0.13

    Requirement:    /SDL2_net-2.0.1 (deprecated. . .?)
    PROBLEM>>  Slackbuilds do not support it for Slackware 14.2, the only build is from Slackware 14.1
    Compiled and installed:  SDL2_net-2.0.1

    Requirement:    /Zlib-1.2.11 (upgraded from 1.2.8)
    Have: zlib-1.2.11

    The libraries as I have listed them here did work for compile.
     

  13. The problem is that you need to have your IWAD in the EDGE root. EDGE can also read from DOOMWADDIR and DOOMWADPATH variables, respectively. We have been brainstorming a way to write an IWAD selector, ala ZDoom or Eternity - but have not came up with any solutions as of yet. Are you building from source? Make sure 'edge.epk' is in your root folder with all of the other folders/dll, and copy/paste your IWAD in the folder. I'm working on "couldn't open file" to be a little more verbose, as well. EDIT: Big ol' long spiel about video cards and drivers -- turns out EDGE was issuing an extra glFinish command when it was being done a little earlier in the I_FinishFrame loop. Dumb bugs like that always kill me!
  14. Coraline

    Complete iwad list

    Also, speaking of the IWAD list, we need to add "Rise of the Triad: Dark War" - since EDGE validates it and work is ongoing to support the game.
  15. I apologize for the outdated information - lib_versions.md was written while we were in a transitional state from Make to CMake, and I honestly forgot I had created that document in the first place. Alas, I have updated it for completeness' sake. Note that we only need six out of those ten libraries now -- once OpenAL support is finished we won't need libogg or libvorbis either. You are also free to use the setup scripts in the directory /quick_setup_scripts, but I have only really tested on x64:Xubuntu so I can't say for certain if those scripts will work for Slackware or not, or if a custom one will need to be rolled. Please try the updated instructions out and let me know if you are still running into problems.
×