wesleyjohnson

No DOS from me right now as my DOS system is down. I installed the latest Linux and have switched to it, and it may be a year before I have everything working again, if I ever get that far. The DOS testing was being done by someone else, and we got as far as my fixing all the problems that he had found. There is a fair chance that if you have DOS and a compiler that you may be able to compile Doom Legacy. I had not achieved getting my compiler on FreeDOS to work. Depending on your memory available you can enable and disable options in DoomLegacy. There is not only the make_options, but also the doomdef.h file that can be customized. UMAPINFO should work on DOS perfectly fine. It also got support for DeepSea patches and some other modern blockmap stuff, so you can play Lost Civilization and some other modern wads. There may be others who have a site where they post Doom Legacy binaries for additional systems. I never know how long these things last, nor can I seem to keep track of them. I have made contact and sent the binaries off to the team member with official access to the SourceForge account. He did say that he can make the 64 bit binaries so they may get done this time. We will have Linux SDL, Linux X11, and Windows SDL binaries. It may compile for DOS and MAC too, and BSD and other unix-like. The bug fixes in this version may be few, but they are notable, especially for Windows 11 users. We finally got the music fixed on Windows 11.

Have committed the latest release of DoomLegacy, 1.48.14. Binaries will be released, I don't know when, depending upon when the other people involved get around to that during this busy holiday season. I have already reminded them about making the 64 bit binaries too. SourceForge-DoomLegacy From the whatsnew. 1.48.14 SVN1657 (2023-11-30) FEATURES 1.48.14 * UMAPINFO, derived from umapinfo-lib (GPL) written by Michael Bäuerle, who has allowed us to use and modify it in DoomLegacy (FR_0100). In DoomLegacy the original library code got heavily modified, eliminating use of FLEX and YACC, removing internal structure hiding, and making it embedded in DoomLegacy. Errors and messages were rewritten to attach to DoomLegacy error reporting. * Add viewfit control. This allows a wider monitor to be used with drawing at correct aspect ratio. auto: auto select based on actual screen size. stretch: stretch to fit screen. fit width: fit to screen width, scale to correct aspect ratio. fit height: fit to screen height, scale to correct aspect ratio. BUG FIXES 1.48.14 * In Pagodia.wad, Map06, the hanging vine texture had visual artifacts. (AUR008, texture #624, lump 132961). Due to some of the patch columns being totally empty, some of the columns of the generated texture had the 0xFF termination, in the wrong place. Fixes bug 687. * In Lost Civilization Map04, the arch texture ARC1ABRN was rendered with black holes. The wad uses it on a wall and as a masked texture, next to each other. These two uses generate incompatible texture formats. The use on a wall had texture generation using the TM_picture format. The masked use requires a TM_masked compatible texture format. To fix this, gave the masked texture draw the capability to generate an extra texture_render holding a TD_2s_ready texture. * The MIDI output included some padding of Track 0, that caused the Win10 and Win11 MIDI player to delay the track and change it to a piano. Do not know why these were in the MIDI output. The Track 0 padding has been disabled, and may be removed entirely (eventually). The Program_Change inclusion is now enabled by control variable "midi_create_program", which is default 0. The midi compression is enabled by control variable "midi_compress", which is default 1. These are not in any menu, can be changed by console. This fixes bug 0674. * Add JOYSTICK_SUPPORT compile-time option, so that joystick code can be disabled. This was necessary due to some port situations not having joystick hardware. * Steven Newbury has been trying to compile for DOS. These are changes based on a something he summitted. I suspect this may not be complete. It covers some network problems with DOS. Within djgppdos, there are DOS sound fixes and many other fixes to bring the DOS port up to date with the interface. * Fixing complaints from gcc 11.2. Also snprintf does not honor string max field size. Must copy possibly long strings to some shorter buffer first. The code_size seems to have been reduced by 56K, perhaps due to new compiler. * Fix error from w104_23. When BOB_MOM code was made a standard feature, one of the compile tests was missed. Removing the BOB_MOM define, made some of the old code active again. This may have had some obscure effect upon when the weapon bobbing stops. Have removed that old code. Some other cleanup, ptr declares. * Disabled a RANGECHECK in wi_stuff as many wads violate those assumptions. Fixed many other typo and ptr declares encountered while working on UMAPINFO.

The difference between 400 and 480, is probably whether you include the status bar in your filtering or not. On DoomLegacy, you can select several alternatives for the status bar, one of which is an overlay. Depends on what woof has and which ones you use. The larger number may be the safer choice.

I wish to thank those that contributed to the project with debugging information. Many of the bugs fixed would not be found without them. As I do not run Win10 or Win11 at all, all bugs on those ports are dependent upon someone sending me detailed information and debug logs. This is not everybody who has contributed. These are the ones that I could find in the notes that I could actually find at this time. But, Thanks to everyone, even those that did not get mentioned. I know I must have missed somebody. Michael Bäuerle : UMAPINFO, DeePsea tall patches, and reporting bugs in advanced wads. latern424: MIDI on Win10 and Win11. He sent a detailed report and ran a special instrumented version of DoomLegacy that finally diagnosed what was happening. Adam Stylinski: Network packet analysis, and numerous detailed reports. Steven Newbury: compiling on DOS Mr. Rocket: who is always available for answering Windows questions, and testing things

WIth recent update, I have had to deal with a piece of old code. It cannot be correct as it was. Strangely, it was in 1.43, and is in PrBoom Plus. It is in wi_stuff.c. It tests for the wi prev and next map numbers being within a valid range. The old code, tests against the map range of 0..8, for Doom2 commercial. I believe that range would only be valid for Doom1. I have changed mine to this code. You can use this if you wish, and even comment. #ifdef RANGECHECK // [WDJ] Verified that doom2 will call here with maps 1..32. // printf( "WI RANGECHECK: episode=%i, lev_prev=%i, lev_next=%i\n", wbs->epsd, wbs->lev_prev, wbs->lev_next ); int map_max = 8; // This has been 8, (checked 1.43 and in prboom). int episode_max = 0; if (gamemode == doom2_commercial) { map_max = 32; // Doom2 maps } else { // Doom1 and Heretic map_max = 8; episode_max = ( gamemode == ultdoom_retail )? 3 : 2; # ifdef ENABLE_UMAPINFO if( game_umapinfo ) episode_max = 99; # endif } # ifdef ENABLE_UMAPINFO if( game_umapinfo ) map_max = 99; # endif detect_range_violation(wbs->epsd, 0, episode_max); detect_range_violation(wbs->lev_prev, 0, map_max); detect_range_violation(wbs->lev_next, 0, map_max); detect_range_violation(wbs->pnum, 0, MAXPLAYERS); // detect_range_violation(wbs->pnum, 0, MAXPLAYERS); // duplicate, appears in PrBoom too #endif

I did really suspect it would be like that. Thanks RjY. Even without umapinfo, the wad makers had broken it. It was a lost cause. This was a RANGECHECK, not enabled normally. I do not know what they were trying to protect. It worries me a little that there just might be something that could break. But even umapinfo must be limited to to 255 maps, and 255 episodes. A RANGECHECK should be able to test for those limits. Can't be negative either. Like most ports, DoomLegacy has added checking on just about everything, which should be adequate protection now. I suppose I am going to have to verify that. I see no good reason to keep it, and could just delete it entirely now. It did not get committed. Thanks for the comments.

Slackware 14.2 and Slackware 15, running on Athlon (custom build).

Linux hardware MIDI ports are addressed using an ALSA system. You can start by >> man aplay >> man aplaymidi >> aplaymidi --list >> aplaymidi --port=14:0 If you cannot get your game to select that port, you could configure /etc/asound.conf to default route the midi to your selected device. Most games are hard-programmed for the default MIDI, which for Linux is TiMidity (at least for me for the last 25 years). TiMidity attaches itself as the default MIDI device. Look at "https://www.alsa-project.org" for a doc "Asoundrc - AlsaProject". I have it but do not have a link to it. Get more help at linuxquestions.org Portmidi sounds like portaudio, which is a mixer library that has to be installed. I do not have a hardware midi, so lack any better experience. I have been configuring ALSA, and fighting PulseAudio, and I also re-wrote the MIDI for Linux in DoomLegacy. I have a ton of information on that. If you are using SDL2, then that will use FluidSynth. I was unable to convince it to use TiMidity. It probably has the same problem with MIDI hardware ports. I have looked at SDL2 code, and it is not a simple config problem. If it finds FluidSynth it will use it. It includes FluidSynth in itself if there was not one installed at compile-time, so cannot get around it.

It is part of the DEBUG options. DoomLegacy has more control over these options and made it easier to enable them. It may be in most every port, even if it was not normally enabled. It may be fixed in some ports, I do not know. This code was active during latest development and was getting triggered. And it was broken. I am more interested in if anyone agrees with this fix.

The code puts them into a sorted list at sprite creation, each frame. Some of them get discarded immediately if the list has gotten long enough. I use an insert sort that is much faster than the draw. A single draw of a nearby sprite would be on the order of 65K operations. A draw of a more distant sprite is on the order of 1500 operations. The sprite list is never allowed to get longer than twice the selected limit. If the limit is set to 100 sprites, then insert is in the order of 400 operations, and that is only after the list has grown to full size. The rejection tests come first and after the size reaches the limit they prune out the losers early. Pruned sprites do not have to get drawn at all, and there is much saved in not calling any draw functions for them (cache fighting is reduced by never referencing their data). What also helps is a randomized pruning. It is not a fair pruning, as it must be fast. This makes the sprites that are on the edge of the display area, only get drawn ever few frames. As the player only sees them every few frames they appear to flicker, which is an interesting distance effect. This allows the existence of the more distant sprites to be seen by the player without slowing the frame rate to a crawl. On any map where you have sprites being treated this way, there are literally a quite a few closer monsters that are more important threat and have your attention. In any case the sprites sorted by distance is needed for software draw anyway. If the user has selected a draw limit of 100 sprites, then the closest 100 sprites get drawn normally. There will be an additional 100 sprites that get drawn conditionally, selected by distance and randomized pruning. The sprite sort list will never exceed 200 sprites, even if there are 1000 sprites visible on the map. I used a wad with a very large number of monsters during the development. Before, I would get a frame rate of 1 frame every 3 seconds. Now, any frame rate slowdowns are not even noticed.

The four posts right before mine are. Why don't you give them an example using woof, and we can see your syntax. I don't have gzdoom, so if anyone does, give that as an example. I do not know of any doom port that does not allow specify of -iwad and pwad files from command line. There is no need to rename a wad and drop it into the directory. That is something that has persisted for over 20 years as the method for making doom play a different wad, and it is not necessary. I tried it a few times (20 years ago) and it does lead to having wads named DOOM.WAD, and you no longer know what they actually are, so do not do that if there is a better way.

I have kept DoomLegacy compatible with older hardware, especially with software-rendering. I prefer to play large maps using direct 32bit draw in DoomLegacy as it looks better than GL, and is FAST. There is also a setting to handle large numbers of monsters. It will only draw the closest monsters, according to your selection. I had trouble with nuts.wad until I put that in. Now it will handle nuts on any machine. Most of that was developed on a single core Athlon, using Linux. The windows version got tested on an old WIn98 machine for a long time, but now is tested on an old WinXP machine. 800x600 is generally a good screen size for large maps. It is what I generally use. Can also play MBF wads. DoomLegacy does have some optional assembly routines, but they are currently disabled because the latest compilers produce code that is just as good, and does not need to be update manually every time I touch that particular code.

The DoomLegacy backend for midi supports Linux MIDI hardware port, timidity, fluidsynth, and is selectable. Took a long time to work out some of the problems, so you might want to look at that. Never got to test the MIDI hardware port as I did not have the hardware. Look at the linux_x backend, as the SDL backend is not as capable. SDL2 will not let you use anything except Fluidsynth, and will build it into SDL2 if you do not have on your system. I never won that battle.

HocusDoom must be a PWAD, as it modifies the loaded maps of Doom2.wad. There are many other things in the doom2.wad besides the maps and the monsters. They probably replaced stuff, during development, bit by bit, and it would take an extended examination to actually discover what they had not replaced. It would be an exercise in obscure details to remember something that they probably missed. Probably was not worth the trouble, so they left it as a PWAD. To play ChexQuest properly requires some modifications in the Doom engine. It has some capabilities that are not in standard Doom. Play it with a fully capable ChexQuest engine. The DoomLegacy port has considerable code to support ChexQuest, like the fireflies.

Calling all your doom wads "doom.wad" will just lead to confusion. On most any Doom port there is a way to specify the doom file you want to play. Example: >> doomlegacy -game doom2 -iwad doom93.wad This goes back to the original doom. This may also be done from within the game, if the port has a console. If you are using a click-start, then a doom-launcher gives you the appropriate selections and does the same thing. DoomLegacy, for example, has this built-in. Just check what the syntax is for gzdoom.

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. (Edit: DoomLegacy 32 bit binaries are now available: DoomLegacy 1.48.12 ) 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.

From the point of a source port, that is trying to be "Boom Compatible", I must firmly disagree with any "moving target" interpretation of "Boom Compatible". For the purposes of source port compatibility, I take Boom compatible to mean being compatible with what the original Boom source code allowed. I would also refer to as a reference, what PrBoom (but not PrBoom+) did to support Boom, because of the testing done upon it. I exclude PrBoom+ and later revisions because there have been additions and changes to the code, and it is hardly ever clear exactly what source compatibility a particular piece of code intends to support. I would apply this also to players who want to define "Boom Compatible", on the basis that I do not see any good reason for them to have a significantly different definition than the source ports use.

Some of the users on this forum not want to wait for this to reach an official release. It is committed to the SVN source. SVN 1648 Have fixed a long standing problem with Windows MIDI. For some reason, which I could only conjecture about, one of the MIDI tracks had been padded out with 33 zeros. Timidity, Fluidsynth, Win32 MIDI, and probably every other MIDI, has ignored these. The rationale for having done this has probably gone away with DOS and early Windows, so I have disabled them. The report from some Windows 10 and Windows 11 users is that this fixes the MIDI music problem where one MIDI track changes to a piano. It was also sending a Program_Change command with a blank title string. This has been made optional, default disabled. * LOG Fix to Bug 0674 Midi track playing late. The MIDI put out included some padding of Track 0, that caused the Win10 and Win11 MIDI player to delay the track and change it to a piano. Do not know why these were in the MIDI output. The Track 0 padding has been disabled, and may be removed entirely (eventually). The Program_Change inclusion is now enabled by control variable "midi_create_program", which is default 0. The midi compression is enabled by control variable "midi_compression", which is default 1. Thanks to lantern424 for providing sufficient information and testing to identify the nature of this problem. Thanks to lantern424 for testing on Windows 10, and MrRocket for testing on Windows 11.

During DoomLegacy updates to DeHacked code that must have been from the DOS period, I discovered that it OVERWROTE const strings when the text or name was modified by DeHacked or BEX. This will crash many systems. I have not read your code yet, so you may have done this already. But from reports of crashes, it sounds like not. So, I must recommend that you use an allocated string system, such as in DoomLegacy, for all text and strings that DeHacked can change. In DoomLegacy there is a compile-time option to abandon or recover the old strings. Searching DoomLegacy dehacked.c for DEH_RECOVER_STRING should get you to deh_replace_string(), which will lead you to the appropriate locations. There is also a hash of the original string, that is used to allow replacing the same text string from multiple DEH source files. This happens with some mods. Otherwise when the first DEH mod, modifies the text, the DEH in the wad file can no longer find it.

Thank you old systems users, and the users of old systems, for your support and interest. Exploration of sites like vogons, does not reveal much of any pattern. It seems to mostly users wanting to get such and such running on some old hardware. Keeping the DoomLegacy software configurable seems to be the best I could do. Some more auto detection would not hurt.

I was interested in whether people would flock to SDL2, just because it was newer, or most would stay with SDL1 because they had that on their hardware. In the Linux users, we have SDL 1, leading over SDL 2, by one download, with X11 download trailing those by one download. Many people are forgetting to download the common download (according to the download stats). Some people may be using the old Common download from the previous version, which probably works, but does not give them the new docs. Flightgear and a large number of games do the same thing, this is not a new concept. Tis the year end season, so the 64 bit downloads may not show up for a while. I have heard from those members, so they are alive.

The DoomLegacy 32 bit binaries are up at SourceForge. Do not know when the 64 bit binaries will arrive, as those are built by members who run 64 bit. There is also source code. Do not forget to download the common package. DoomLegacy 1.48.12 SourceForge has mangled the README file in the display. The copy in the download formats correctly with any other reading tool. DoomLegacy will compile for many other customizations, but I do not have the machines needed, and other excuses.. We provide what we think would be the most useful binaries.

Thank you for your extensive listing. It looks like Doomsday uses an older SDL_Mixer (1.2.7.0) than DoomLegacy does, but requires minimum Win 2000. Most ports just used the latest SDL available when they were working on it. That those last 4 are using 1.2.11 and still work on Win95 is useful information. I may just look at vogons etc, just to see what old hardware people are still running, and what they are doing with it. For some reason, DoomLegacy has significant numbers of users that download the old versions. I may keep one old hardware compatible version around, just to see how many people download it. Then I would only need to have the run-time version detection handle 1.2.10 and up. It depends upon how much code is actually saved, so if it does not save much, it might just be moot. Not saving much to rip out code that is already there and tested.

Does anyone have machines for which they need (or just find it better) to run older versions of SDL 1.2. I have an XP machine that uses SDL_Mixer 1.2.8, which is missing some functions that SDL_Mixer 1.2.12 has. This is not a popularity poll, so I am not counting responses about the latest windows, nor wanting to hear about how EVERYONE some person knows is limited to only using certain versions. If you know anything about how old Doom is, and how old some of the machines that people try to run it on, how old the SDL Mixer 1.2.8 library is, has no importance what-so-ever in this. Complete silence is not going to mean that I am going to rip-out any support code. It just means that I will have to do alot more research and testing to see what hardware and OS are limited to only running these older versions, before I even consider doing anything of the sort.

If you are using DOSBOX, then you would be running DOS binary (not chocolate doom, unless they have a version out that I am not aware of). This would be fine if you were going to run the one of the original ID Doom binaries. Launchers are for starting a Windows binary Doom without using a command line, (maybe some other OS too). This would be fine for running a Windows Doom, or Windows Chocolate Doom (but then you do not need DOSBOX). If you have a command line, it is easy enough to use the command line. DoomLegacy has a basic text Launcher built-in, and will search directories for the wad, DEH, and zip files. In case that would solve any problems for you.