wesleyjohnson replied to Gabenslair's topic in WADs & ModsI thought I wrote a book on this ... Top worse things: 1. Learn by dying. In any map design, if you are expected to learn where the traps and monsters are by try and die, I will often die and find something else better to do. 2. Nose-grinding This includes fake walls with normal wall textures, doors with normal wall textures, and anything else with a switch that has a normal wall texture. Two objects on a wall is not an indication that it is a fake wall (like some very plain early wads did), it is decoration. 3. Shoot-switches with normal wall textures. Cannot expect that players are going to go around shooting innocent walls. 4. walkover line that opens a hidden door, who knows where Don't care what you use it for, it requires the player to search the entire floor to find out why they cannot advance. The player does not even get to know they successfully did something. 5. teleport hordes of monster traps That is not playing the wad, when you have no choices the wad author is just playing with you. 6. twitchy finger exercises Having to run the player to beat a door, or dance over some pillars, or some other finger exercise that is best suited for 9-year olds with nothing better to do. The equivalent of the ball and cup toy. How many times will you try to get that ball to land in that cup? Did you feel that the accomplishment was worth the time invested? I will only try a few times. Once I have sucked all the adventure out of the exercise (which is quicker than most authors seem to think), then I will use a cheat to bypass it. I call it "player digs a tunnel". 7. the rat maze Anything that looks like it belongs in a psych laboratory. It is just as bad when it has bits of cheese at selected dead-ends.
There was some question as to building the latest EDGE on Linux. I downloaded a ZIP of the GIT. I am not sure that was the right way to go about it. First I checked out the library requirements. Out of 10 libraries, I have problems with 5 of them. My system was updated to the latest packages from Slackware last month. I suspect that the package versions listed are not actually requirements, but are actually what happened to be on the system they used for development. I tried to compile anyway. I sent the results to Coraline by Doomworld email. The compile failed due to the physfs library. They are using a pre-release version of phyfs-3.0, and my current phyfs does not have all the functions they are using.
Results of testing the compile of latest Edge on Linux.
I tried to compile EDGE on Linux. I don't have exactly the right libraries, so this failed.
But, I ran through the compile anyway to see what would happen, and to detect other errors.
You have instructions for Visual, but the Linux instructions are somewhat hard to decipher. They should be explicit.
The instructions in build_guide/MAKEBuild.md -- do not work --
>> make Makefile.linux
I tried the CMake system instead.
System: Slackware 14.2, Linux 4.4.88
# 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.
fatal: not a git repository
# ignored this error and continued on
Error file w_wad.c
PHYSFS_EnumerateCallbackResult does not name a type
PHYSFS_Stat was not declared
PHYSFS_FILETYPE_DIRECTORY was not declared
PHYSFS_readBytes was not declared
These are not in physfs-2.0.3
I am stuck until my physfs library gets updated.
I really do not want to install a bleeding edge pre-release version.
DoomLegacy Development Team
I apologize for the outdated information contained in lib_versions.md. I've just pushed a change to that file for the repo. Since we don't have many dependencies anymore, this is the list verbatim:Quote
/physfs (3.1), https://icculus.org/physfs/
* Note that the reliance on libogg and libvorbis will soon go away when we finish re-implementing OpenAL. Also, you no longer need any external image loading libraries nor do you need libCPUID, as those are handled internally by EDGE now.Quote
3DGE Library Versions
This document outlines the libraries 3DGE needs for compile.
Please note that all libraries **must be statically linked** to the EXE (except for SDL2 on Win32).
-- WHY, on Linux too ??
They don't need to be explicitly linked on Linux - I have since used and compile EDGE for Linux a lot more than I did when that document was created so I have a much greater understanding of the Linux operating system. I compile and test on x64:Xubuntu by the way. Those statically-linked requirements are really only for Windows versions (which follows the overall convention laid out by EDGE 1.35).
So, go ahead and clean out your directory and pull fresh - just make sure you have the latest physFS, libogg, libvorbis, and SDL2 2.0.8 (though EDGE will compile with SDL 2.0.6 if problems arise with sound output).
Please try the updated method and let me know what your results are.Spoiler
Also, you can use the /quick_setup_scripts directory/files to install the needed dependencies automatically if you don't want to do it manually (or are unsure where to find latest versions of said libraries). Though this has only been tested on my end using 'ubuntu-getdeps.sh', so just be aware of that if you do use these scripts.
Results of testing compile of latest Edge on Linux.
I tried to compile EDGE on Linux. I failed.
These are the library requirements that I encountered.
I don't know if all these libraries are really required, or if some are just for Windows.
This document outlines the libraries 3DGE needs for compile.
-- WHY, on Linux too ??
System: Slackware 14.2, Linux 4.4.88
I have already upgraded to the latest packages of the the Slackware site, 8/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 have recently upgraded my system, and I do program development.
There are way too many latest libraries listed here, and some are the
latest bleeding edge versions.
I suspect that these are not actually the required versions.
Out of 10 libraries required, there are 5 libraries that I would have to
upgrade or install.
If these were available as Slackware packages, it is likely that I would already have them.
These may not be available as Slackware packages for some time.
PROBLEM>> dont have this package
Requirement: /libcpuid (0.4.0, upgraded from 0.2.2)
PROBLEM>> dont have this package
Requirement: /libjpeg-turbo (1.5.2, developmental version)
>>> Are you actually using features from 1.5.2 that are not in 1.5.0 ??
Requirement: /libpng16 (lpng1632)
PROBLEM>> dont have png16
Requirement: /physfs (pre3.0, upgraded from 2.0.3)
PROBLEM>>> bleeding edge version required
Requirement: /SDL2 (2.0.5, upgraded from 2.0.3)
Requirement: /SDL2_net-2.0.1 (deprecated. . .?)
PROBLEM>> dont have this library, and it is deprecated ??
Requirement: /Zlib-1.2.11 (upgraded from 1.2.8)
PROBLEM>> requires a minor version upgrade
>>> Are you actually using features from 1.2.11 that are not in 1.2.8 ??
Cross-Compile users (Unix-based) must build these libraries from scratch. Just look
at the version table above and you should be fine.
SLADE does say that the two music lumps are ogg. I tested the wad. They do play through DoomLegacy without any special code. If SDL will play ogg lumps that way, then I suppose it would play MP3 lumps too. I had SLADE extract the DRUNNIN lump and I played it using ogg123. It sounds the same as in the game. I could not get music out of SLADE. My hardware device has to hook to ALSA, so ALSA is my primary sound device. Even though the pulseaudio test button works, I don't seem to have pulseaudio sound now (I did at one time).
Is there an easy answer to where in rc-dc.wad the ogg lumps are. Are they replacing any music ? What should I hear when I am listening to the ogg ? edit: I tried it and heard music, but I could not tell if it was ogg or not. Erratic music with kettle drums. I would rather not have to reverse-engineer the wad to figure out where the ogg was in it.
Yep, that is just about what you have to do to use PNG. There are other reasons why I will have to do that eventually, and the most compelling is to support wads that have PNG textures. There is some advantage to using PNG for textures, it reduces the wad size (ok,some people still care about that). When that time comes I will probably include PNG as a screenshot format. Up until then, I cannot see screenshots as a strong enough reason to deal with PNG right yet. Mostly because of that need to deal with this for so many operating systems. For the few screenshots that people take, they can convert them to PNG or any other format they want using more any paint program. I got lots of other plans for improving actual play that feel more important right now. And, right now, I have to get some income oriented work done. Thanks, I saved the STB project README for future reference.
Any port that stutters on your current machine, is going to keep stuttering no matter what speed hardware you get. There is something that causes a stall, and it is not going to go away just because you overclock more. It will just use more clock cycles when it does stall. On DoomLegacy, I gave it a control to limit the number of sprites that are drawn per frame (closest have priority). This fixed the slowdown on wads with hundreds of monsters. You just adjust it until you get the response that you prefer. There was a frame rate comparison some years ago, presented in this forum. The only thing I remember is that DoomLegacy had the highest frame rate, (due to careful programming he said). I run 1.6 GHz CPU, with 900 MB memory. I play at 800x600, so that is adequate, even for OpenGL. Doubling the resolution requires 4 times the CPU speed, and video card speed, to keep the same responsiveness. Video cards are already maxed out, and they are the bottleneck for OpenGL, not the CPU speed. (With software rendering it is almost all CPU speed, but I expect that you are using OpenGL rendering.) This means that you are not going to get much improvement for all that expensive hardware. You get more effect by reducing the resolution you play, even a little.
wesleyjohnson replied to ukiro's topic in Source PortsThe skies should be drawn to keep the horizon line in the sky texture at the same point on the screen for all texture heights and all screen resolutions. The horizon drawn by the ground flats, and the horizon in the sky texture need line up to look right. How high up the screen the mountains are is not as important. What happens to be drawn at the top of the screen does not matter much. PrBoom kept the horizon consistent. GZ has the horizon line all over the place. No one should be changing their sky textures to adapt to this inconsistency. If and when this gets fixed in the code, any "fixed" skies will now be mis-positioned. Viewing below the horizon was typically blocked by the rendering of the ground. In some wads, you could walk to a balcony , and would be able to see the repeat of the sky texture below the horizon. I have felt that for most usages, drawing any sky below the horizon as black would have served better. On wads that decently hid the view below the horizon it would not matter, and it would look better for those wads that allowed seeing below the horizon.
The Newdoom forum did have the old discussions. The link seems dead now. I have notified the site master. No plans to move to GitHub. I doubt that is much of an issue. Subversion is working just fine for this project. The real problem is that so many people want to start their own port, so they can experiment and add features of their own choosing.
Again, about the old Launcher included in the windows binary ... In the game page, If you do not use any path names when specifying the IWAD ( i.e. doom2.wad ) then the Launcher does not put the doomargs in the wrong directory. The only requirement is that the IWAD files must be in one of the directories that DoomLegacy searches, such as /games/doomwads. So, just specify doom2.wad, let DoomLegacy find it by searching directories, then the Launcher works much better.
I have not tested this, I haven't even looked at the music code, but .. I suspect that if DoomLegacy got Ogg music from a lump, it would pass it to SDL music. The interesting thing about SDL music is that it supports multiple music formats, including Ogg. [From SDL site] SDL_mixer is a sample multi-channel audio mixer library. It supports any number of simultaneously playing channels of 16 bit stereo audio, plus a single channel of music, in FLAC, Ogg Vorbis, MP3, MOD, and MIDI formats. As of SDL_mixer 1.2.7, FLAC, MOD, Ogg Vorbis and MP3 loading libraries are dynamically loaded, so if you don't need to load those formats, you don't need to include those shared libraries. [end] It does depend upon whether your SDL library was compiled with the Ogg support. It is possible many ports that uses SDL, could be capable of supporting Ogg music. Of course, that would be too easy. Just as likely to be some odd test for midi in the port or some such hindrance. Anybody got a way to test this. First step would be to have some Ogg music in a wad ... Anybody got one of those.
For anyone who might be trying to use the old Launcher that is included with the DoomLegacy Windows binary. If you get the "doomargs.tmp file not found" message: The old Launcher is putting the doomargs.tmp file in the directory where it finds the IWAD. I don't know why it does this, as it makes no sense. I assume it then passes a command line string to doomlegacy that does not mention any directory for the doomargs.tmp file. This is a bug in the Launcher, it is not consistent in the location of the doomargs.tmp file. It did this for an absolute IWAD path C:\doomwads\doom2.wad It did this for a relative IWAD path doomwads\doom2.wad I do not want to copy my entire doomwads directory into every install of doomlegacy. Trying to use shortcuts did not work, in either direction (on an XP). A file indirect of doomargs in every directory that has an IWAD might make it write the doomargs file where it is supposed to (but apparently not available on an XP). There are other Launcher programs out there, but don't know how compatible they are with DoomLegacy. This one is not that compatible as it is. KB1 is looking at the Launcher source code. As he programs for Windows, at least he might have a chance of figuring out what is going on. MrRocket reports that it works for him. You just have to have the wads in the directory with the doomlegacy binary. That may turn out to be literal and a requirement for using the old Launcher. If you have wads in other directories there are two ways to start DoomLegacy. 1. Use a command line console box, type in command lines. Faster. 2. Start doomlegacy without any command line switches so it goes to the built-in launcher. Provides some lines to fill in and a game control.
Are you still having trouble with Linux?
I have Edge 1.35, but have not compiled it for Linux 4.14 yet. The old binary does not run because it uses glew 1.4, and the this Linux 4.14 uses glew 1.13, so I will have to recompile it.
Which version of Edge ?
Wesley Johnson, DoomLegacy Team
You want to try compiling for the newest version of EDGE, which is at the Github:
We have removed a ton of references to libraries like jpeg, png, libcpuid, glew, and a host of others. This build system uses CMake. There is quick_setup_scripts you can run to get the libraries you need, but they need to be updated to remove the ones we no longer use (guess I can do that now)!
Sorry I just got your message here @wesleyjohnson, but please let me know if you are able to get it compiled for Linux or if you need any assistance!
The Windows binary is up on SourceForge. The Windows binary still includes the old Launcher, which works for some people and not others. The problem is that for the old XP (the Windows I have, used for testing), the Launcher fails to write the settings in the doomargs.tmp file. If this is a new install, doomlegacy will then give an error message about "doomargs.tmp file not found". If it was run previously, it will reuse the existing doomargs.tmp file, with whatever doomlegacy settings that were in it. For those that are interested, bits of some ongoing conversation. ---- About the message "Response file doomargs.tmp not found" From my experiments, if you get that error then the Launcher is not writing the doomargs.tmp file. That means that the settings from the Launcher will NOT be getting to doomlegacy. If you set the file by hand, then doomlegacy will only ever get what you put by hand into the doomargs.tmp file. If you are getting the doomargs.tmp not found error, you should abandon the old external Launcher and start doomlegacy directly from a shortcut. You can edit the shortcut, have one that starts doomlegacy with "-opengl" for example. I recommend starting doomlegacy without any command line arguments, so that it starts the built-in launcher, which is not as pretty as the old external Launcher, but is functional. It also handles the new settings that the old external Launcher does not know about. However, you have to read docs/legacy.html command line switches to use it. ---- It could also be dependent upon how the Launcher is started. I have been doing a "cd" to the Legacy directory and trying to start the Launcher from a File Manager. Maybe it only works if it is started from a desktop shortcut. I passed on installing that, and that may be the problem. Putting a doomargs.tmp file in the binaries directory makes the error message go away, but the Launcher is useless because none of the settings get through to doomlegacy. It is not writing a new doomargs.tmp file when you change the settings. ---- If you are going to test the Launcher, you MUST use different settings for each test. Otherwise you will not be able to identify when it fails. Once you have a doomargs.tmp file present, then a Launcher failure will only fail to write a new one (with the new settings), and the Launcher will simply reuse the old one. You must test with different settings each time, so that it is obvious when it has failed to write the new settings to the file. The simplest seems to be changing the game from UltDoom to Doom2 to TNT, etc. as that will be obvious when it starts up in the game mode from a previous session. ---- I may have to drag the old Win98 machine out and test the old Launcher on that. But would that even be relevant anymore .. ---- This discussion has been about the old Launcher that is included with the Windows binary download. DoomLegacy itself is running fine. On my XP test machine (and only on the XP machine), it seems that the sfx sound has low volume, and the music is lounder. For those who have problems with the old Launcher, you need to abandon using that Launcher, and start DoomLegacy by other means.