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

wesleyjohnson

Members
  • Content count

    1403
  • Joined

  • Last visited

7 Followers

About wesleyjohnson

  • Rank
    Senior Member

Recent Profile Visitors

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

  1. wesleyjohnson

    Why is Eternity not so popular?

    As there is this thread about EternityEngine, so this is a dump of an EnternityEngine problem. Just warning you, I am not looking for help, just telling you the latest irritation. This is where the INSTALL procedure for Linux could use some work. My motherboard failed, so I am rebuilding everything for the new hardware. I found the latest release for EternityEngine, 4.01, and tried to build it. 1. The build instructions for Linux seem to consist of , make build dir, cd to build dir, and run cmake. I already know this is not adequate, there must be a configure, and a install. 2. I cannot find any instructions for how to pass options into the CMake build, or what options are available in Eternity. From DoomLegacy I know about doomdef.h, and I assume that I could change options in there, but this doomdef.h looks more like a definitions file and not like a user configuration file. 3. I would prefer to build binary for my specific processor and not for a generic 486. I am trying to adapt a slackbuild script to do that, but it appears I will have to reverse engineer the cmake files to accomplish that, and I rarely use cmake, so that is going take some time. 4. I know there are data files in /usr/share/, but I have no idea how they are going to get installed. Am I going to have to do that by guess again ? 5. There is no list of Requirements for Linux using CMake, so I cannot determine if this will run on my system, or what I would need to get it to run. There is a Requirements list for Mac, and those are libraries that I do have. 6. An attempt to run cmake, just to get something, failed with a fatal error. I do not have "adlmidi" and that seems to be fatal. There is an adlmidi directory in the source, but it is empty, so that is a mystery. There is no adlmidi slackbuild available, so this is going to take some time to accomplish. Requirements did not mention needing adlmidi. I already have Timidity and FluidSynth. Why does this require another midi synth ? It couldn't use the available Midi support like other ports do ? This is where I stopped for the day. I already got several fires to put out so this is going to have to wait until I have some time, like maybe January. I might try version 3.4 again, as I managed to somewhat get that installed on the old system. So for now I still do not have a working Eternity, and that does hamper its popularity.
  2. wesleyjohnson

    Why is Eternity not so popular?

    The EternityEngine map that I played had some portals. That is what I remember as being the big feature. However, the portals were not finished. There was some implication that the portal code needed some work, and I never heard that it was finished. Some thoughts about portals: Random connections using portals are not much different than those teleport lines, or teleports, except that you can see through them too. But randomly connecting parts of the map is just confusing. Random connections adds confusion, and I really prefer that my natural sense of orientation not be sent into disarray by a portal maze. An Esher map is fun about once or twice. What is more interesting about portals is what can be accomplished with them to design a good map, that looks normal. What map features can we create with this tool ? What can real-world structures can we build with this, that we could not before ? It would help the mappers to create a mechanics guide to building stuff using portals.
  3. wesleyjohnson

    Why is Eternity not so popular?

    I would like to once to be able to discuss another port without someone invading the discussion, obsessed with touting GZDoom as their ideal. I don't buy that hype and the constant harassment is just obnoxious. Please discuss EternityEngine here, and the features of it that could be worked on and features it probably would want to avoid. I would prefer EternityEngine as it is, over any OpenGL only port. OpenGL results vary, and the player is at the mercy of the implementation, while software draw is more consistent across machines. Need to keep software draw around, at least as a fall back, even if you did prefer OpenGL glossiness. OpenGL has often looked as if someone plasticized the game, and I don't care for the plastic look. I regard the software draw appearance as the ideal, and the differences in the OpenGL draw, and that glossiness, as bugs that need to be fixed. So, I would not advise going OpenGL preferred with Eternity, as I regard the accomplished software draw features as its better assets. Adapting to the player preferences, including odd ones that you may not have use for, is why I emphasized having good options menus. The player needs to adapt the game to their preferences. Many players have no wish to be coerced into abiding by the preferences and ideals of others, no matter who has predetermined what they should like and what they should see as an ideal. There is no need to change the name, it is fine. I cannot imagine calling it by any other name.
  4. wesleyjohnson

    DoomLegacy 1.48.6 Release

    From the Just- cannot-win category of bugs: DoomLegacy 1.48.6. Bug 0670, Monsters mysteriously disappearing, moving large distances into the void space. This mostly escaped detection in testing, as it only affects a few monsters, and is only noticeable when monsters show up in the void space. This is caused by a broken calculation to determine the opposite direction. This bug was introduced in the moonwalk patch (svn 1540) when I copied the opposite calculation code from PrBoom, in an effort to reduce differences that might lead to bugs, replacing a table lookup implementation. However, the PrBoom calculation must be guarded against DI_NODIR, which the table implementation could handle inherently. Without that protection, an olddir of DI_NODIR introduced a direction of 12 into the logic, which can only handle directions of 0..7, with NODIR=8. Several times a game that 12 value would survive long enough to get used, which would be expressed as a wild walk movement. Fixed in SVN 1563. Both options were fixed, with the fixed calculation barely winning a speed comparison over the table lookup, and having a slightly smaller cache impact. Having monsters escape the play area adversely affects all games played with 1.48.6, so another release will be scheduled soon. There will be some testing now, to make sure of the bug fixes. In the meantime, on some maps some monsters will escape into the void preventing 100% kills. DoomLegacy Version 1.48.4 is not affected, but some other bugs in that version were fixed in 1.48.6. It has not escaped my notice that this bug was caused by reverting to PrBoom code, in an proactive effort to prevent subtle errors due to having slightly different implementations.
  5. wesleyjohnson

    Why is Eternity not so popular?

    Yea, with DoomLegacy, same problem. On my machine, I have DoomLegacy as my main port, EternityEngine, PrBoom, EDGE are playable. I have code for ChocolateDoom. I have abandoned ZDoom and everything from that line. I do not find OpenGL that much more appealing. My favorite setting is 24bit drawing, which has smoother visuals than 8 bit palette and much faster and smoother play than OpenGL. I do not like the flashy eye-candy graphics. I play for the mechanisms and engineering, the exploring. Those have to work smoothly, not roughed up by a slow rendering engine like what happens with OpenGL. The following is based on memory, as I am in a cycle of installing software after a motherboard failure. Some of this may be remembrances of PrBoom or EDGE too, but I will try to talk around that problem. It is not necessary for every nitpicker to pick all the nits out of it, as the points are not going to be that specific to just EternityEngine. With EternityEngine, I could never quite figure out the settings. It is not my main port so I am not going to memorize very much stuff in order to use it. The stuff I need to setup is going to have to be more easily setup and the correct settings more easily found. Settings that are 0 or 1, or On and Off, can be confusing as they require the player to understand exactly what the control is turning "ON". It could be enabling a feature, or enabling compatibility with Vanilla, or Boom code. It is easier to deal with settings that say "Vanilla", "Boom", "Fast", "Slow", etc.. It would be best if the control told the player exactly what it was doing, and not require the player to have learned and memorized exactly what the EE engine does, or what Boom did. Most of the compatibility controls in PrBoom are just mystery settings, and I have no idea what behavior they changed. Moving the player around was rough. I am used to DoomLegacy freelook and cannot play a port that connects the mouse to running instead of looking. As soon as any monster shows, my muscles aim on their own, and the player rockets all over the place. Having the player controls be able to adapt to the player is necessary, you cannot expect players trying out EE to adapt themselves to it. They will just get frustrated at the lack of control. This means going overboard on giving the player the ability to tune the keyboard and mouse controls. I suggest stealing some of DoomLegacy mouse control code as I have spent enough time on it in the last couple years that it must have something new that you can use. When in doubt give the player a control so that they can choose, rather than have them feel stonewalled. They will just accumulate reasons to try other ports. I don't remember the EE menus being that bad. It was difficult to remember where to find settings as it seems to be page based. DoomLegacy also has extensive menus, but I invested some time in developing a good push down menu system that can nest menus and can pop back (dynamic not static). This allows sub menus that can be entered from more than one place in the menu tree. Thus we can organize menu items by function, such as visual effects in one menu and game compatibility settings in another. The menu tree is not very deep (three pages deep) but the player can browse freely as there are links to sub-menus where needed. Using a similar scheme might relieve some of the menu frustration. Adding multiplayer is both an attraction and a curse. I have spent half a year reworking multiplayer on DoomLegacy, where it was already well established. Multiplayer will absorb all your time, and it will affect everything else, and interact with everything else. There is the attraction that now two players can play coop. The deathmatch attraction is already covered by many other games, and others besides Doom. The usual deathmatch is highly dependent upon having an existing base of many players who have invested time and experience to use the same identical engine and same rules. You would be fighting an uphill battle to establish another deathmatch community from scratch, so that is not a good place to invest your time.
  6. wesleyjohnson

    DoomLegacy 1.48.6 Release

    To clarify: Not implemented in any of the DoomLegacy Ports, such as SDL, X11, DOS, MACOS, WIN32, (does not refer to other project's Doom ports). All of the DoomLegacy ports had a non-functional dummy for the Disk ICON function, so I made that code conditional on LOADING_DISK_ICON.
  7. wesleyjohnson

    What are the latest source ports that work on Win98SE?

    DoomLegacy uses SDL 1.2, and has good native draw, so it does not require OpenGL. I still got the Win98 machine setup, that was used for testing before I got an XP machine donated. Actually had to use the Win98 recently (it has Linux too) when my main machine motherboard developed buggy SATA ports.
  8. wesleyjohnson

    DoomLegacy 1.48.6 Release

    DoomLegacy 1.48.6 is now available at SourceForge https://sourceforge.net/projects/doomlegacy/files/ FEATURES 1.48.6 --- DoomLegacy can read zip archives (Linux Only, enabled by compile option ZIPWAD). When a load file is a zip archive, all loadable files within the archive are loaded. When searching for a known file, zip archives of the same name (but with .zip) are also searched. This uses library libzip. When built with compile option ZIPWAD_OPTIONAL, DoomLegacy detects if the libzip library is present on the user machine. This allows DoomLegacy to run without the feature, when the user does not have libzip. A libzip before version 1.2 does not have a seek function. A compile option will provide our own zip_seek function, so libzip 1.0 can be used. --- Recorded Demos now include both the Version and Revision numbers, so revision specific behaviors can be enabled. DoomLegacy 1.48.6 has modified its native demo format, which is revision specific. Older demo formats are still playable. --- Recognize and handle DeePsea Tall patches. Enabled with compile option DEEPSEA_TALL_PATCH. Michael Bauerle submitted the orignial patch, derived from crispy doom. --- BUG FIXES 1.48.6 --- DoomLegacy and PrBoom monster infighting does not have missile invulnerability between monsters of the same species. Some other ports (Boom, MBF, Eternity engine) do not have the infight test, so their monsters are always invulnerable to missiles from their own species. Added another item to the infight control to select the behavior. Implements "Full Infight" setting with missile damage (Legacy, PrBoom). Implements other infight settings without missile damage (Boom, MBF, Eternity). Fixes BUG 0664. --- Added MBF infight logic, thats stops monsters from firing on friends. --- Legacy demo would fail to start due to blocking the textcmd that loads the map. The Legacy 1.48.4 demo was recorded with player 0 issuing the map textcmd. Player 0 was not in the game yet, and this was detected as a textcmd from a non-existant player, which got caught by new security code. For textcmd issued before player 0 is in the game, the demo needs to use SERVER_PID. Fixed demo read to redirect player 0 demo textcmd to SERVER_PID. DoomLegacy 1.48 has a single long combined textbuf, containing the textcmd from all players. Within the combined textbuf, there are individual textcmd marked with the player id. Individual textcmd are still limited to 255 chars as in an ordinary textbuf. The DoomLegacy 1.48.6 demo format has been changed to store the entire combined textbuf buffer into the player 0 slot. This is simpler for recording and playback, has the same effect, and allows SERVER_PID textcmd, which the previous demo format did not. The commands to create a player (and other server actions) are now issued by SERVER_PID, where in older demos they were issued by player 0, before player 0 existed. DoomLegacy 1.48 has better protection against malicious network traffic than previous versions, and checking textcmd validity is part of the security protection. This fixes demo playback to work with the security checking. Changed the SERVER_PID to 250 now, for future expansion of players. This fixes bug 0665. --- Fixed the moonwalk bug, where monsters would sometimes walk backward. This was due to a bad translation of an everything-in-one-expression to more maintainable code. --- Make an oof sound when hit a 2s line, just like when hit a 1s line. Adopted from PrBoom, a Killough enhancement. --- Make optional, and disabled, some old development hacks. Option DEVPARM_LOADING: Loaded development wads from a special directory. This used switches -wart, -devgame (even older -shdev, -regdev, -comdev). Option WADFILE_RELOAD: If a filename started with a tilde "~", it was taken as an indication to reload the file on every lump access. This was to enable leaving doom running while changing wad files. Option LOADING_DISK_ICON: Not implemented in any of the DoomLegacy ports anyway. --- The Full Graphics startup was fragile, requiring constant fixing. Video startup now changes directly to the config modes, which is faster and cleaner. Removed some antiquated code and interactions, adopting an interface that puts the main code in control. --- Fixed the violet line, trees, and tall sprites of "Lost civilization" wad. This required being able to save the same texture as both a transparent patch texture, for drawing hanging vines, and as a picture format texture, for drawing tiled walls. This fixes Bug 0663. The fast drawing of wall textures required them to be a power-of-2 in width, so they could be tiled. To handle the case where it is not a power-of-2 in width, it now uses a slower masked draw similar to that in PrBoom, which also handles a negative offset. This fixes the large tree in "Lost civilization". --- Fixed some old code to use POSIX fcntl, which allows it to compile on SunOS. Patches submitted by Michael Bauerle. Fixes Bug 0666,
  9. wesleyjohnson

    Good lightweight source port for quick LAN?

    First, you need to mention what OS, and what range of CPU speed. With that kind of question, any and every port could be suggested to you, because even the early Doom had network play. Does the chocolate doom stutter when in single player ? DoomLegacy has advanced features for network play. It is developed on Linux, and has been tested with a Linux machine, and an XP playing. With an erratic connection it will tolerate it for a while, then try to repair the player position, but when it cannot recover it will kick the offending players. DoomLegacy does not stall if another player is late with their network packet, it continue. One advantage is that you could set it to use native draw, at 800x600 resolution, which is much faster and does not require good OpenGL libraries. It looks much better than 8bit palette draw of the older ports. You could also use the splitscreen to both play on the same machine, but then should configure a second mouse.
  10. wesleyjohnson

    Doom Legacy issues

    Sorry, I have not been visiting Doomworld very often, and I seem to have missed your question before. Just released the 1.48.6 rev 1550 version (which is working its way through our release system), but is in the SVN now. I develop on Linux, so I don't get to test much on Windows (other than XP) . But, I have run it on the XP and it does not behave that badly, so there must be a setup problem. The last time I had anything that resembles this description was when I accidentaly got two copies of doomlegacy running at the same time. It did not seem to have started, so I tried again. In the end, it was just starting slow, and both attempts became active. Only one had the screen, but the other was running too, and they interfered with each other in some way. It was a 2GHz CPU, which should be able to run more than a few copies simultaneously, so they must have been locking each other out of some contended resource. I did not figure this out until I gave up and shut the system down, then noticed that I was getting duplicated Doomlegacy shutdown. Beware, Windows can take a long time to get DoomLegacy started. Suggest you must wait it out. It starts in about 3 seconds on Linux 4.4.
  11. wesleyjohnson

    How can I work on my own Source Port? (not a joke)

    You should pick source code that was developed on your platform (which seems to be recent Windows). Much of the early Doom code was developed on Unix (Linux) and then to DOS. If you want to program on Windows, then DO NOT start with Doom original, Linux Doom, Boom, PrBoom, MBF, DoomLegacy, or most any port from that era. The system interface is not going to be Windows familiar, and you won't be able to easily make it Windows familiar. While DoomLegacy has a Win32 port, it is meant to be compiled using MinGW using POSIX compatibility libraries, not some IDE. Other Doom ports are similar in that they have been developed using a specific compiling context. This is usually not the one you want to use. Modifying the compile method for the compiling context (IDE) that you want to use is possible, but that is hardly every documented (at all), and is a can-of-ugly-worms type of problem. Until you have a good grasp of compiling it and making modifications on a working version, you should avoid trying to change that to work with CodeBlocks or anything else extensive. Porting to another platform is hard because nothing much will work until most of the porting is done. There will be pages of error messages that must be solved one by one, and they probably are interrelated, so already knowing the Doom code well is necessary to make reasonable progress in a month of work.
  12. wesleyjohnson

    Tech Idea: Cross-Port Intermediate Demo Format

    That is the one reason a new demo format will not result from this, everybody has different goals. From the title of this thread, my proposal is very much viable and on target. Some people have gotten excited about being able to scroll through a demo like it was a video. That is not really the main function of a Doom demo, which is to record the play for later playback. It is possible to scroll any demo playback, if the demo player being used transforms the demo to some reversible format, such as proposed. If it saves the playback details in that scrollable format as it plays a demo, it can scroll back the demo and replay. Not every port needs to use that scrollable format for Demos, just the one that wants to scroll the demo playback. That scrollable format then can be tailored to that port, and does not need to have insane levels of compatibility with the other ports (insanity is what happens to the port developers trying to maintain that compatibility in such a monster format). Because it records so much detail, that scrollable demo format is going to be incompatible with every other port. It does not address the problem of why demos are not compatible between ports, so it is not likely be common to all ports. I already consider demo formats to be broken, so they are a low priority item on DoomLegacy in the first place. A scrollable demo is not on my list of needs for a demo format. A new scrollable demo format, designed for some other port, is just going to be a pain to maintain. Why would such a thing be desirable for any (all, most, whatever portion of) the port developers reading this. To get a common format that most port developers could implement, it will have to have loose requirements, like in my proposal. Everything added to the current demo format will have to be optional and extremely flexible in recording, subject to local interpretation in playback, and each optional part must incrementally improve the playback accuracy individually, as any part may be re-interpreted or ignored by some of the ports.
  13. wesleyjohnson

    Tech Idea: Cross-Port Intermediate Demo Format

    I have been considering the similar concept, a demo format that is more robust. DoomLegacy has already modified the demo format for its own use. It records facing angle as an absolute, instead of a relative difference from the previous facing. DoomLegacy also tries to fix network play sync issues by updating the absolute position of players on the client machines. I feel it would be easier to just fix the errors of a demo, rather than try to record everything. Close to sync is adequate, as long as the time and distance of de-sync is limited. Important interactions need to be fixed, such dead or not dead. This minimizes the amount of new work that is needed. The doom ports already can reconstruct the replay almost correctly, so keep that and refine it. Keep recording keyboard input, due to it being the most important data. Let the recording machine add postings that add to the fidelity of the result. There are other formats that behave this way, adding refining information that is optional. Create a way to identify monsters, such as by sequence number or position, or mobj id. Players can be identified by player number. Periodically post the absolute position and angle of each player. Once every two seconds ought to be enough. When a player is damaged, the player position and health is posted as absolute values. Periodically post the absolute position and angle of a monster. One or two monsters each frame should keep them close to sync. This can be variable or controlled by a user setting without affecting compatibility. When a monster shoots, post the initial position, angle, and momentum of the monster, and the projectile. When a monster is damaged (by anything), post the position, angle, momentum, and health of the monster. When a monster dies, it's death is posted, identified by id. When a monster spawns, it's spawn is posted, with position, and a new id. Keep the positions in fixed point format. Slight errors are tolerable, as another absolute update will appear before it becomes significant. Important interactions will recorded as absolute events. One significant problem will be during playback, the engine discovering an interaction before the posting in the demo is read. It might be possible to find the demo posting of the interaction, and block of the engine doing anything about the interaction it discovered. EDIT: on second and third thought, trying to block anything the engine does on its own is a can-of-worms. The engine should just do what it does normally, and let the demo postings adjust the results. During playback, make it possible for a demo posting to always override whatever the engine may have done on its own with a discovered interaction. This can be as simple as having the demo postings just overwrite the player and monster values with more accurate values. It may have to recreate a monster or mobj, so it may be safer to put mobj in a recently-died fifo, just in case the demo is found to still be using them. Playback of demo postings, might have to create or kill a monster or player or object. This would fix the inevitable differences before they accumulated large enough to affect interaction. The important results of an interaction would be directly made absolute. The demo playback may be constantly slightly out-of-sync, but this demo format deals with that situation. It can continually bring monsters and players back into sync. The adjustments may be slightly visible, but that is far better than the total de-sync that is commonly experienced now. As all new parts of this demo format are optional, this can be expanded and modified extensively without affecting its port compatibility. The tic format would have to be re-formated, as there is little room for additional information now. EDIT: Put postings between the tics in the demo recording. During recording, the tic command is written first, then the tic command is executed. Significant events that happen during the tic execution might be recorded as postings after the tic command. During playback, the tic command is read, then the tic command is executed. Significant events will be discovered by the engine. Then the postings after the tic command are read. These adjust and correct the values of positions, angles, etc, of the player, monsters, and objects. This lets the engine execute normally, but refines the accuracy of the result. Health, Death, and object existence is always fixed.
  14. wesleyjohnson

    DoomLegacy 1.48.4 Release

    Have added the ability to read a ZIP file, as of svn 1544, which is SVN current. ZIP file reading is only available for Linux right now, as it uses libzip, which I do not know how to access in Windows or other ports. Have started testing for Release 1.48.6, which should be very soon. Need to release those bug fixes. Have one fix for corrupt demo recording, which is probably not used by many people, or I would have heard more about it.
  15. wesleyjohnson

    Do you use texture filtering? Why or why not?

    Consider first a texture that has within it a smooth transition, such as a glare spot, or a curved surface where the curve is represented by a smooth color transition. The doom textures are small and it is likely under sampled in the doom texture. Thus, what was supposed to be a smooth transition has jaggy edges and there are sudden transitions in color. Also, it is paletted color, so there are sudden transitions in color, period. Using filtering when displaying such a texture at a higher resolution will help to smooth this out. It will look better. Unfortunately, many of the textures in Doom also are already composited from smaller textures, and have sharp edges. The sharpness of the edges is variable, from pattern on the wall (semi-sharp), to text, signs, indicators, switches, and the like that have edges that need to remain sharp. Any application of filtering will smooth out the sharp edges in the textures. All the sharp edges within the textures go blurry. A higher level texture filter sometimes can try to preserve intentional sharp edges while still smoothing smooth transitions. But, for the small Doom textures there is not enough information in the texture for such a texture filter to tell the difference between a sharp edge and a jaggy from color paletting. Good ones are not offered by the video cards anyway. For texture filtering to work, the engine would have to keep all textures broken up into individual elements and draw them individually, allowing the filtering to smooth the jaggy transitions. The sharp edges between individual texture draws would be preserved (I am assuming that there is no filter applications after OpenGL compositing, but only during texture sampling). There are only a few Doom textures that have this compositing available, and this would be extremely tedious and difficult to generate. It is a non-viable solution. The solution that works is to substitute higher resolution textures for the originals. The person generating the higher resolution texture can determine if an edge is to be preserved sharp or blended better, and it does not need to be done by code or at run-time. This is also time-consuming and tedious, but the level of effort required to do it by hand explains why no simple texture filter is going to do an acceptable job. The other solution that works is to turn off the texture filtering, and just let your eyes blur a bit. Addendum: Using texture filtering may give you some eye strain. The Doom textures have sharp edges between objects within a composite texture, but the texture filters will blur them. Periodically your eyes can strain trying to find a focus that eliminates the blur between distinct objects.
×