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

    What ports would require a legacy/retro system?

    DoomLegacy is doing fine on the modern Linux. It opens fine on Windows too, does not require obscure hardware, nor does it require Win98. It does have some options for compiling it for DOS, Win98, OS2, BSD, and MAC, but that for those who want to compile it for one of those older OS. The SDL windows binary is compiled on a modern 64 bit version of windows. Some of the older SDL versions were responsible for some problems. Some users have reported that the latest SDL for windows fixes some of their problems. I am developing on Linux, then checking the windows port on an XP. It is being tested on modern versions of Windows by several hundred users, and I have not heard of any that it does not run on. If you mean the windows idiom point and click system, then you have to know how to use that to deal with a command line option rich program. Most people try to use the old Launcher. Because of that, the old Launcher is still being shipped with the windows binary (probably for the last time). The Launcher that was shipped with the last windows binary is likely going to be dead (again). We cannot find the source code that was used to create it, and older source code versions have shown even more problems. The problem with it is that the wad files specified to the old Launcher need to be in the directory with the binary executable. Otherwise the old Launcher screws up to which directory it puts the autoexec file that it builds. Do not give that old Launcher any absolute path names. But that is a problem with an old Launcher that has been declared dead and unsupported, several times now. Work is being done on replacing the old Legacy launcher in three ways. There is a replacement launcher developed by Exl, there is the built-in launcher, and there are the menus. The built-in launcher can handle almost all the command line switches. But you still have to know the command line syntax, and the command line switches. You do NOT need to use a Launcher to start DoomLegacy on a point-an-click windowing system. It has several other ways to specify the same settings, such as autoexec file, built-in Launcher, and the console. I never use any Doom launcher, even on Windows. More of the command line switches are being brought into the menu system. There are a few switches that at this time, still must be on a command line. Those are the ones that the original Doom versions used to configure the entire Graphics system. Those switches made irreversible selections. I have been adding functions to reverse those actions, so those selections can be made in the menus (work in progress for next release). But, just about every function in the Video and Graphics interfaces has to be rewritten, and a whole lot of texture and patch handling needs tracking and unloading capability. If you don't use a Doom Launcher then you can let DoomLegacy search for the wad files in its list of known wad directories. It will find the wad, even if it is in a subdirectory. I would think the easiest point-and-click way to start DoomLegacy would be to just create one of those program indirections, and specify the command line switches you want on its command line. Just use that to start the program each time. It usually would need to specify the game, the graphics mode (opengl), and any added wad files. You can also use the built-in drop-down console to specify added wad files. This can be done after DoomLegacy starts, or even after playing another game. You can specify custom configuration using an autoexec file with console commands. Then just edit the autoexec file for which game you are playing. This has the advantage of saving that setup so the same game can be saved and continued later without having to guess at what configuration you specified.
  2. wesleyjohnson

    EDGE 2.1.0 Discussion [RC-1.5 Released on 10.17.2018]

    I am still having a problem with identification of Edge versions. At https://devbuilds.drdteam.org/3dge/ there is EDGE-x64-2.1.0-RC2-g582ad08bc.7z Nov 29 2018 So there may be a RC2 version now. BTW, I cannot run that because it is 64 and I am 32, but I was looking for source anyway. Found some Source at https://github.com/3dfxdev/EDGE but cannot determine any version marking. It might be RC2, or it might be something after RC2. It looks like the best I can do is mark it as the 2018_11_23 version.
  3. wesleyjohnson

    Doom Legacy 1.47.2 Release

    I am also working on bringing as many of the command line controls into the menu system as I can. Right now I am changing the config file system to allow more flexibility. It will allow loading a common config file, a drawmode (OpenGL) config file, and a user specified config file, and it will remember which config file each control variable came from so it can save them to the correct config file at shutdown. The user can edit the config files to select which settings are unique to a drawmode or specific situation. This will fix the problem with having to define all the control keys again when switching to OpenGL. The OpenGL config file will only have those entries that the user wants to change for OpenGL. The config loading system will remember which those were. I have not quite got the drawmode to change from the menu yet, partly due to OpenGL having its own separate config file.
  4. 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.
  5. 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.
  6. 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 !
  7. 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
  8. 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.
  9. 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" ?
  10. 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.
  11. 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.
  12. 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.


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

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

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