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


  • Content count

  • Joined

  • Last visited


About wesleyjohnson

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. wesleyjohnson

    Marshmallow Doom v0.667 (Nov. 2018 update)

    I also was working on having some kind of item sharing, to put in Legacy. Not only because I like the coop play, but also because I was going to add more weapons, and restrict the carry capacity. My plan was to be able to dump weapons on the ground and then the player can pick up what they want. That way there is no going off to menus in the middle of play, and it allows a monster to attack in the middle of this, in a workable manner. The idea is to basically use the ground as the selection menu. The need for this was having a possible 20 weapon types, and limit the player to only 9 weapon slots, so they have to be able to choose a weapon to drop in order to pick up a new type. I like the idea of being able to inventory too. In Legacy, I have the heretic inventory system to work with as a start, but have not figured out how to use it in doom. Now that you have implemented first, I will have to see what you have done.
  2. wesleyjohnson

    k8VaVoom: no good thing ever dies!

    Keep all the controls and settings that you want. I am sure that my selections will vary until I find the right one, and may differ for different maps. I am sure it will be different than what you would want. And highly likely different than those who think there is only one good setting. I prefer having the choice on anything that is questionable. Don't have to make the savegame format future proof. Just save a savegame version number in it. I made DoomLegacy capable of loading the previous savegames since it got a version number. Not that hard to maintain as it is the same optioning of old loading code, which is the similar to any other compatibility code. I actually put a whole header on the savegame so I could identify some other things, like which wads it needed. People tend to forget that when they come back to play it again.
  3. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    I cannot tell if you have not noticed older postings, or have forgotten some issues, or just have not replied to them. Current outstanding issues: 1. I can see the translevel patch in the GIT, but when I pull a master copy, I get the same old code from 10/17, which still fails with the same error messages. I am not understanding GIT, or that patch has not been updated into the master. 2. CMAKE setup does not detect the SSE2 capability of my Athlon64. Now, flightgear does detect SSE2, and it also uses CMAKE. 3. Hoping for response to installation problems. Where is edge.epk supposed to be, and why cannot Edge find it where make installed it, " /usr/local/share/games/doom/edge.epk" ? 4. You have a outstanding message about debugging those last ROTT drawing errors. Addendum: To proceed I tried putting in the patches by hand. I could not make any sense of the line: origsize = EPI_LE_S16( (rottpatch_t*)origsize ); Casting the origsize to a ptr, is not going to have much effect on the EPI_LE_S16, and adding the flag -fpermissive is just hiding the problem. I changed it to: origsize = EPI_LE_S16( ((rottpatch_t*)pat)->origsize ); I do not know if that is right, but it compiles, and it at least resembles accessing the loaded structure. (just for testing the compile)! Testing: Again it cannot find edge.epk, so I copied edge.epk and the EDGE binary to /usr/local/games. SO.. now it starts, I see the loading screen, it goes through GLBSP stuff, toplevel stuff, and Loading stuff. The last lines before it quits were: Loading external Levels Loading external RadTrig Missing Languages !
  4. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    I am going to not try to figure this one out, and leave it for you: Download of Edge-master downloaded 2018-10-18, at 2:30 Minnesota time. Compilation on Linux 4.4.153, using GCC 5.5.0. Error in r_image.cc, line 410: translevel = EPI_LE_S16(buffer, hdr_size); Error: macro EPI_LE_S16 has been passed 2 args, but only has 1. Error: EPI_LE_S16 not declared in this scope. -- I have no idea how it could know it has 1 arg, can point to the def in endianess.h, and then post this error msg. Error: cast from rottpatch_t* to u16_t loses precision epi/endianess.h #define EPI_LE_S16(X) ((s16_t) EPI_LE_U16((u16_t) (X) r_image.cc line 418 origsize = EPI_LE_S16( (rottpatch_t*)origsize ); -- it is right, a ptr is usually at least 32 bit, unless you have the 64 bit version
  5. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    Compiling on Athlon, Linux 4.4.153 When I do CMAKE, There is a line that says "Performing test CAN_DO_ARCHSSE2", to which it says "Failed" I have an Athlon64, which does have sse2 instructions, according to /proc/cpuinfo.
  6. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    There is some commentary on that last ROTT screenshot in your pm. That thing is hard to use, I have to check it every day to see if there is any reply. Was there not some PM that when someone used it, it sent you an email that your doomworld email had a message ? Couple days ago I finally found where the source code is hiding, and now I cannot remember where that was. Following that link to your distribution page shows the binaries. Up on the bar is this "Source" tag, which takes me to another page. I cannot get the source code from that page, and I am not sure what it is supporting, or if it is just broken, or not filled in. So, I seem to need a new source code link. Is there any response to that problem that I had with a previous version (posted Oct 3) where I compiled and installed Edge, had to hand copy the binary into place, and then Edge could not find the "edge.epk" that the "make install" had put into " /usr/local/share/games/doom/edge.epk" ?
  7. Nuts.wad was not serious, nor meant for playing, it was meant for testing large numbers of monsters. I also make more testing wads than playing wads.
  8. wesleyjohnson

    Chocolate Doom on Linux

    I run Linux (but not Chocolate). If you do not have a directory where it is trying to save something, then it is safe to assume it did not save it. You will have to modify Chocolate doom to use a directory that you do have. Or you could make a soft link to make it look like the directory is there. There are probably other problems with your video and mouse hardware support. I think Chocolate doom uses SDL, so the problem is how well the SDL you have supports the video and mouse hardware on that "board". If you don't have SDL, then you might consider trying the DoomLegacy-X11 port, which only needs the X11 windowing system. It also will try to create a directory "/home/yourname/.doomlegacy", where it stores save files and config. For doomlegacy, you can try: >> doomlegacy --help >> doomlegacy -home /home/home_directory -config config_file.cfg -game doom1 Again, if you really need things more, then you have to change a header file and recompile, or even modify some code.
  9. 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


      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


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




      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
      //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!
    4. 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.


  10. 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

  11. 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

    Requirement:    /libvorbis-1.3.5
    Have: libvorbis-1.3.6

    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

    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.

  12. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    Compiling and running EDGE on a Linux system:: Slackware 14.2, Linux 4.4.88, Athlon CPU, 900 MB main memory Compiled hyperEDGE-master_2018_10_02 Compilation successful. There are no instructions on installing the binary and components. Attempted installation via the Makefile (requires root permissions): >> make install It built and installed a file to /usr/local/share/games/doom/edge.epk It did not install the binary anywhere where I could find it. So I manually copied the binary (requires root permissions) >> cp EDGE /usr/local/games Tried to run EDGE as a user. It cannot find the edge.epk Build Log sent to Coraline by doomworld-email
  13. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    I went to Edge GIT to get latest source code. The best I can do is to mark it as hyperEdge_master_2018_10_02.zip. Do you have a GIT numbering system, or an Edge identification system that would uniquely identify each source code image ? In DoomLegacy we use the subversion number to label images uniquely, such as DoomLegacy_SVN1083. Even if we made 10 updates in one day, each would have a unique SVN number.
  14. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    Problem: physfs latest version seems to be physfs 3.0.1 The build docs in Edge GIT, lib_versions_md, seems to call for : physfs 3.1
  15. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    I have been waiting for such a question. In DoomLegacy, I gave it 20 directories that it searches to find the wad. IT WOULD BE NICE, if some other ports searched some of the same directories, so that a person could put one copy of these wads on their system and have more than one port be able to find them. So I would very much like to suggest that you have EDGE search at least a couple of the same directories. You could even steal the entire search function and directory list code out of DoomLegacy (I wrote all that). If we could have some common wad directories that all the ports search, it would save the users some trouble. This is so easy to use. You just specify the wad name, and DoomLegacy goes and finds it. You don't have to remember which subdirectory you stored it in. For IWADS, it will search 5 subdirectories deep in each of the search directories. Because only one (or possibly two) of these directories are found, this search is usually very fast. If you want to specify the entire wad path, it will accept that too. If for some reason, it gets pointed at the users home directory, it will refuse to search that directory. That is for security reasons and a speedup. The list of directories to search is defined in doomdef.h, and can be customized by anyone who wants to compile their own binary. One advantage of stealing our code, is that it has been tested and security hardened already. Some of the file functions are subject to potential abuse in network play so I had to add some protections. For the list of directories searched by DoomLegacy, see the README at the file download page. https://sourceforge.net/projects/doomlegacy/files/1.47.2/ Just change all the doomlegacy specific directory names to be edge instead. I doubt that you want to search the doomlegacy specific wad directories. One advantage of this system is that it supports having more than one wad directory. There can be a system wide directory for common doom wads. It could have another directory specific to Edge wads (that play only on Edge). Each user can also have their own directory of doom wads that is not shared with the other users. The LEGACYWADDIR default specified there is the default value if the environment variable is not found. Same for some of the other default defines. LEGACYWADDIR gets put on the directory search list along with some other dynamically discovered directory names, like the current directory and the directory of the binary. I suppose it would be possible to combine the directory search with a wad selector interface. It could still search some directories, and the user would not have to figure out which subdirectory they put the wad into. On my system, I have the wads sorted by port and game, so wad directories run about 3 or 4 levels deep.