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.

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

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.

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.

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