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

wesleyjohnson

Members
  • Content count

    1488
  • 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

    DoomLegacy 1.48.12 Release

    DoomLegacy very much supports compiling by the end user for the user preferences and libraries. Plan to add support for dynamic detection of the SDL Mixer library, and run-time adaptation to the run-time SDL Mixer library detected. This would make it much easier to create a general binary distribution that has all the features. The Win32 binary is currently created on a WinXP, which limits it only use features available in SDL Mixer 1.2.8. That is my machine for testing that the code still does work for SDL Mixer 1.2.8.
  2. wesleyjohnson

    DoomLegacy 1.48.12 Release

    DoomLegacy 1.48.12 (SVN 1642) has been released. Those who compile their own can get the latest at SourceForge SVN 1643. Our packages and binaries will be forthcoming, once I can revive other members of the DoomLegacy team back to life. FEATURES 1.48.12 Added SDL2 support, as a compile option. This provides video, sound, and keyboard alterations for the SDL2 library calls. The source code still supports SDL1. This supports target machines that are not supported by SDL2. At this point, for some things like MIDI music, we have not yet found optimal SDL2 solutions, so SDL1 is still considered the primary port. Added a control to select music type, with an automatic mode. Added automatic music type selection and playing. This works better with SDL1 than SDL2. SDL2 will always use Fluidsynth for MIDI. It even builds a copy of Fluidsynth into SDL2. Added controls to adjust monster health, health pickup, armor pickup, and ammo pickup. This allows adjusting play of an overly difficult map such as one with multiple cyberdemons, such as when you have only three players on your coop team and one is a newbie, or just adjusting a map weak in ammo. The user can also increase difficulty when feeling cocky. BUG FIXES 1.48.12 Mingw32 does not have strcasestr. Had to write one for Mingw32 and Watcom. Fixed a segfault in biowar.wad Map08 with OpenGL. It would segfault when a texture being drawn in cache, had one patch extending lower than the texture bottom. The cache write now tests against the cache limits, and not the source. Fixed X11 musserver quitting whenever trying any device other than TiMidity. Made the FluidSynth MIDI detection work. Included the DEBUG options. Fixed a HAVE_ZLIB test that would error when compiling for X11. Fixed where Player picks up clip when already has full ammo. A bug was introduced in patch w105_22_playermsg, svn 1225. This resulted in the clip being used up, even when the player already has max ammo. Rewrote the flat animation, to load all flats of an animation. A long time ago the flats were optimized by only loading the flats that appeared in the level map. This is incompatible with flat animation, as the animation requires flats that may not have appeared otherwise. This results in the animation not working for some flats that should be animated (doom2 map17). Updates the flat animation again when levelflats has moved during the update. Removed the old animation code that checked all flats in the wad. Fix the existing MIDI, MP3, and OGG music playing. Fix MP3 music playing, so that it does not try to play it as MUS. Detect the music type upon replay too. VISPLANE_DYNAMIC_COVER. Replaced arrays of [MAXVIDWIDTH] in visplane with dynamically allocated arrays of the current video width. This reduces each visplane from 6464 bytes to 3268 bytes. This will allow MAXVIDWIDTH to be increased, to allow larger screen sizes, without affecting the memory usage for everybody. Transition to new software renderer, to fix sprites that are drawn in conflict with 3d floors. Removed drawnodes code. Sprites could not be sorted into the drawnodes to satisfy all the conflicts that occur. Instead of trying to save all the sprite conflicts in one sprite structure (like a drawnode), the sprite is split and clipped until all parts of it have been drawn (or masked), Replaced openings code (from PrBoom) with pool16 code. The pool16 does not have to adjust existing pointers when expanding the pool. Fix to sprite draw, so that flipped sprites drawing is independent of the sprite x1 position. This fixes draw errors of some flipped sprites. Fixed the OpenGL dynamic lights, where wall textures would distort when a fireball or rocket would pass by. This affected walls under a 3d floor, when it experienced a dynamic light. Fixed a zip seek error that only affected some zip files. Opening a zip archive when there already was a zip file open, required that the zip file be closed, or its file position will be different than our recorded position. This fixes bug when loading cyberarena3.zip. Protect against NULL line ptr in some light functions. This mitigates a segfault in cyberarena3.zip, that was not reproducible. Fixed compile errors in dynamic load of zlib, and libzip. Detect version of libzip from header file. Removed version of libzip from make_options. Add SDL_DIR to the compile make_options. Compile on win/mingw32 cannot reliabily find SDL/include otherwise, and it is better than having end users editing the Makefile. SDL installs with sdl-config are not affected, and most users do not need to specify it. Fixed the new SDL sound code compiling with SDL Mixer versions. It adapts the code for SDL Mixer 1.2.8, SDL Mixer 1.2.10, SDL Mixer 1.2.12, and SDL2 Mixer. This is detected at compile. The SDL Mixer 1.2.8 does NOT have MIX_INIT, but the SDL Mixer 1.2.10 does, and SDL2 does too. The MIX_INIT provides some device detection and reporting to the user what was found. Still supports compiling for SDL Mixer older than 1.2.8, but those do not have RWOPS, and thus music playing with that Mixer will then use the hard-drive. This is detected and determined at compile-time, and running with a newer SDL Mixer will not affect that compile decision. The user must have a compatible SDL Mixer installed (same or better). Newer SDL installs have bug fixes (especially on win), and may be customized to the users machine, so this is up to the user. Changes to support compiling on Mac OS X (Darwin). Uses App folder. Based on support from Gibbon.
  3. wesleyjohnson

    Easiest way to set up a server for me and my friend?

    It helps to start with a port that was designed for multiplayer. DoomLegacy supports upto 32 players, and has a menu page for setting up the server, and a menu page for connecting to the server. The DoomLegacy Documentation, especially the FAQ, has answers to the most common network setup questions. 1. setup your sever on a fast machine, and give it a static internet addresses. Otherwise, you will have to lookup what internet address was assigned to your sever, every time you want to use it. 2a. physically connect the client on the same network. The network range is limited by the net mask, so this usually means the first three address components of the client must be identical to the server net address. 2b. If you are trying to connect to a server at some other location, it will not be on the same subnet. You will have to convince your network to talk to the other remote network (both server and client). If you cannot ping the other machine, then your Doom cannot connect to it either. 3. You will have to configure your firewall to allow outside connections to the server internet address and the Doom port address. Your WIFI router may also have a firewall. DoomLegacy Example: 192.168.26.1 port 5029 4. start the server 5. at the client, give it the internet address of the server 6. Try to connect.
  4. wesleyjohnson

    Doomlegcy opengl, when in the heck did that start happening

    I have a copy of rainbowstar.wad. Some net search says it was created by Jive. I have not been able to find a zipped copy of it, only the copy in my wad database. It needs to get it into a repository somewhere. Anyone have an idea where would be appropriate. Is there a procedure for archiving notable wads of the deceased. Anyone with a Jive archive, or a DoomLegacy archive, should probably just grab a copy of the rainbowstar.wad from the filebin while it is there. << I uploaded rainbowstar.wad and some others here, because I cannot find a site that has it available. DoomLegacy wads filebin. >>
  5. wesleyjohnson

    Doomlegcy opengl, when in the heck did that start happening

    Thank you Brick for that confirmation, it is not video card dependent. Yea, Jive made a map to test and show off Legacy features, along with making other maps for Legacy. See Doomheaven. I am aware of one bug in the MESA implementation that affects splitplayer when using OpenGL. The OpenGL won't honor the window boundaries for each player, at least in the MESA version that I have been stuck with for the last few years. I think that I have a fix at least, even if I don't know why it works. In the dynamic lighting the GL vertexes sow and tow settings (texture positions) are overwritten with some GL lighting sow and tow (which I do not understand at all, yet). As the lighting x,y,z are identical to the wall, reusing the GL vertexes saves some work. As the lighting projection is done after the wall projection, this is normally not a problem, we were done with those texture positions. When I gave the dynamic lighting its own copy of the GL vertexes, the distortion stopped. Tested with rainbowstar.wad and mystic4.wad. Something in the multiple floor loop MUST be reusing those GL vertexes. Need to make a fix that is little more efficient, and does not break anything else. Next release of DoomLegacy, any month now. Thank you for your attention.
  6. wesleyjohnson

    Doomlegcy opengl, when in the heck did that start happening

    RainBowStar.wad is a DoomLegacy demo wad, that used to be available somewhere, and I think I got my copy with the DoomLegacy 1.42. Indications are that it was created by Jive (D. 2011). I would submit it but am not sure of the Doomworld reaction to someone submitting someone else's wad to the database. I uploaded rainbowstar.wad and some others here, because I cannot find a site that has it available. DoomLegacy wads filebin. The site "wad-archive.com" is DOWN. The site Team Hell Spawn is still there, and has DoomLegacy wads, The Jive database at JWD doomwadstation is still there, but does not have rainbowstar.wad. The DoomLegacy site link to DLW ( Doom Legacy Wads at doomwadstation ) does not work anymore. Mystic4 in doomworld ( mystic4 ) is available, and it works too. Mystic7 also is similar. Mystic8 has too many walls that do not show the effect, so is not a good test. Mystic4 shows that it does not need to be colorized, it just needs to have a 3d floor over the wall segment. Open the console, use "god" because there are too many monsters to ignore, and "gimme plasma". Shooting plasma at the omega symbols that are under floors will show many of them distort when the plasma approaches. Note: shooting a plasma at the omega on the top floor (while standing on the bottom floor) will have the omega on the bottom floor distort. Figure that one out. Some DoomLegacy wads are at Team Hell Spawn ( doomheaven ). They have mystic4 and mystic7. This is Linux 4.4.xxx using MESA. I don't think the Radeon is going to be the problem, not unless I start hearing that users of other hardware or OS are not seeing this. I cannot see how an OpenGL problem could be so specific to the wall texture being under a 3d floor. Note: this may have been around for the last 15 years, and this is the first that I noticed it. But, I have stood on that Yellow floor many many times while being shot at, and some of those times must have been with OpenGL. How could I have not seen this before ! And yes, when I pretty much come to a conclusion before anyone else responds, I guess I am talking to myself. Thank you for you attention.
  7. wesleyjohnson

    Doomlegcy opengl, when in the heck did that start happening

    Turning off the Dynamic Lighting in OpenGL video effects stops the weir d texture scrolling. (Video > OpenGL effects > Dynamic Lights --> OFF ) Thank You, but I suspect some 3d floor code interaction now.
  8. wesleyjohnson

    Doomlegcy opengl, when in the heck did that start happening

    I am not seeing it on the top floor. It seems you must be in a colorized, middle or lower 3d floor. That is awful specific for such an weird effect. You may be able to tell that I don't trust this Radeon OpenGL implementation much. Some days I wonder if it is really accelerated, or just faking it. None, of my old video cards will fit into any slot on this new motherboard.
  9. wesleyjohnson

    Doomlegcy opengl, when in the heck did that start happening

    I currently got a Radeon on-the-motherboard video, due to an older motherboard suddenly not being able to handle hard drives anymore.
  10. I just recently noticed a bug in the OpenGL rendering of DoomLegacy, but only in the colored 3d floors of rainbowstar.wad. When a fireball, or rocket passes by a wall, the wall texture will scroll along with the fireball. This seems to be any sprite that generates a corona. However, I have not seen it on any other wad. It seems to be the same with any old version of DoomLegacy, as far back as I have been able to test so far (still onging). I am wondering if it is my OpenGL implementation that is buggy. Is anyone else seeing this on rainbowstar.wad, the colorized 3d floors. Easy way to test is to stand in the Yellow area of the 3d floors and watch the fireballs pass by.
  11. wesleyjohnson

    What source ports fix the buggy blockmap?

    There is this MAXRADIUS. It controls the blockmap range searched when checking most everything blockmap related. In DoomLegacy and PrBoom, MAXRADIUS is set to 32. So, it checks blockmaps as if the maximum radius of a thing (or monster) was 32 units. So, Spider is a bit bigger than 32, so it does not check for blocks far enough out from center. Has anyone tried, just changing MAXRADIUS to something like, 128.
  12. wesleyjohnson

    What source ports fix the buggy blockmap?

    This description in the original post would be severe enough to warrant a fix in most every port. But it seems that is not what is being discussed now. There will not likely be a total consensus on the spider mastermind. Generally, if all shots to the body have effect, do you really need shots to the legs to work ? What, exactly, are you trying to fix. It seems very ... vague. There are probably several fixes, to the "Blockmap bug", with different effects on gameplay. I expect that most of the major ports already have addressed this issue and some fix or mitigation is already present. Unwanted side-effects need to be eliminated. Why should fixes to the hit box be affecting the player/monster collision. This implies that this proposed fix is in the wrong place. What hit-box coverage are you proposing to be adopted. In my description of shooting at the spider mastermind, saying that shots to left knee were ignored, is describing what I was aiming at. How else are we going to describe how much coverage the hit-box around the spider mastermind has on that test map. The facing of the player when MAP03 starts, is outside the leg of the spider mastermind, and should NOT hit. One way to describe it might be that the shooter being in a different sector, should not affect the hit box. That it should emulate the hit box that would result if both the player and monster were in the same subsector. There are so many angle dependent complications in determining hits, that I expect the hit-box to never be a totally consistent thing, and so describing a particular hit-box as being the best, is not going to be port independent. Another way to describe it is that shots to the torso of a monster should always be effective. Fixes that affect the player/monster collision seem to me to be an undesired side-effect that needs to be eliminated. I think that it is entirely possible to eliminate such side-effects, they are not inherent. That only happens because your fix is to the checking subroutine, and affects all uses of that subroutine. If the shooting use of that subroutine was fixed instead, there would not be any side-effects. How much the hit-box searching must be expanded is not clear, as that depends on what hit-box coverage is necessary to meet the requirements. As I said, those requirements have not been stated clearly.
  13. wesleyjohnson

    What source ports fix the buggy blockmap?

    Tested with DoomLegacy. Map01: zombieman died with two shots Map03: spider felt it, turned around and killed me. Then I found the shotgun. I shot it from where I picked up the shotgun. It felt that too, and turned around and killed me. If I shot at the left leg, it had no effect. Shots to the left knee were ignored. Shots to the body were effective. Shots to the right knee joint were effective.
  14. wesleyjohnson

    How exactly did the linuxdoom sndserver used to work?

    DoomLegacy is related to linuxdoom. Probably easiest to just use what you need from DoomLegacy. Whatever method you want to use, DoomLegacy probably has the code for it already. There are log files in the source code package (logs/WDJlog), and I have individual patches (which can also be extracted from the repository). Running the sound server as a separate task makes the sound cleaner because the system will interrupt to service the sound server. The operating system ensures that the sound server is run often enough, and when events happen to it. It does not depend at all on what Doom is doing, or how long it is going to take to finish it. Doom can even go and read disk files (notoriously slow and a music killer). When the sound is directly played by Doom, the sound is at the mercy of how fast Doom can finish drawing, and can it get back and refill the sound buffer before it runs dry. If the buffers run dry it causes noise in the sound and music, and the drivers declare an under-run condition, and that error then must be cleared. If the sound buffers are made too large, then there is a noticeable delay when trying to stop a sound, or play different music. Large sound buffers cause sound latency. The sound seems to always be reacting slowly, leading to sound artifacts. A gun shot will not play when the gun is fired, but will be delayed a bit because all the stuff already in the mixed sound buffer must be played before the driver even gets to the newly added gun shot. Mixing all the current real-time sounds together for the next period is what the sound player must periodically do, and must do it reliably without fail. Make that period too short and Doom will fail to get back in time to add more, and the buffer will run dry (very audible). Make the period too long, and new sounds will be delayed for the duration of that period. ---- SDL sound For SDL and SDL2 sound: see doomlegacy/src/SDL. The SDL and SDL2 sound do not use the Doom sound server code, that is taken care of by SDL (which I think launches its own sound servers). There is a option to compile for SDL, or SDL2, so the SDL2 compatibility has also been taken care of. The SDL2 port currently will only play MIDI using FluidSynth because SDL2 includes a copy of FluidSynth in the SDL2 library, always uses it when it can, and provides no way to force something else to be used. FluidSynth sounds weird compared to TiMidity, but that may be due to the instrument package it uses. I you are going to use SDL2, you do not need the Linux sound servers. In the DoomLegacy source code, there is code for handling SDL and SDL2 sound. It has DoomLegacy mixing the sound effects, so that latency is low ( see I_UpdateSound_sdl ). You only need the sound functions from the src/sdl/i_sound.c files, which will mix the sounds and send the buffer to SDL (SDL2). Music uses the SDL mixer, which can handle various music formats (including MP3), and does not need much servicing. The output of the SDL music mixer is fed into the DoomLegacy sound mixer automatically. That is, the SDL music mixer will have already put the current music mixed data into the mixer buffer that the sound effects mixer is using. ---- Linux sound For Linux sound: see doomlegacy/src/linux_x. Linux sound only applies if you are compiling for the X-windows target. The DoomLegacy Linux sound server was recently updated to fix a whole host of bugs. There is an option to compile a sound server, or it can play sound in-game. The sound server plays better, but cannot tell the main program when it is done playing. The Linux sound and music provide for selection of the Linux device used to play sound and music. There are a separate sound server and music server, each which connects to DoomLegacy by a pipe. The id parameter is a sound id number. DoomLegacy uses a function, I_GetSfx, to load the sound lump and send it to the sound server through the pipe. I believe the original code would have the sound server parse the wad file itself and load the sound lumps. DoomLegacy Linux sound adopted the Michael Heasley doom music player (1995-1996). The current DoomLegacy is still sending the wad filename to the music server, and the music lumpnum, and the song name. The music server must get the music lump itself. The music server uses readwad.c (from the Michael Heasley doom music player) to read the wad, and extract the music lump itself. ---- Other The Linux port code also has an option for Allegro, but it has not been tested in ages. The FMOD option just gives you messages that FMOD is not yet supported.
  15. wesleyjohnson

    What source ports fix the buggy blockmap?

    Have not seen this with DoomLegacy. It has is a fix in P_CheckPosition that checks adjacent blockmap units (out to MAXRADIUS) because things may overlap into other blocks. It sorta sounds like that may be the same thing (or NOT). Do you have a test wad yet, that we could use to test if a port has the problem, and for testing the fix ? I cannot remember having seen anything like this, in playing DoomLegacy for 20 years, so maybe DoomLegacy has it fixed too.
×