wesleyjohnson

So the release SDL_mixer 1.2.12 did not play the MP3, in spite of having the smpeg dll installed ? Was there another dll that was required to support MP3 ? Was there a compile option that might be required on that mixer. That is why these always turn into long debugging sessions. (I have a number of such debugging sessions concurrent right now for various issues on various different programs, and now on multiple OS too).

Thank you. I have downloaded all the files that seem to apply. There are 11 files released for SDL 1.2.12 mixer and 10 more files released for SDL 2.0.8 mixer. That even the SDL official releases have so many variation releases for the same mixer version makes it difficult for any game binary release to include the one and only good SDL library. Cannot do much with the 64bit releases. I rely upon some other supporters to provide 64 bit support. I was hoping to get a 64 bit Linux running sometime soon, but do not have that much need for it as 32 bit does everything with better performance on this machine (and it does have access to the 64 bit instructions which people seem to not understand). Just because there are some people who want to argue about this: ( Explanation: 32 bit binaries are incompatible with 64 bit binaries because of the ptr length. What instructions are supported is important but is already covered by what target the binary supports. A 64 bit Athlon can run in 32 bit or 64 mode. In 32 bit mode it has 32 bit ptrs, which only take up half the cache space while running, compared to the same program running in 64 bit mode. It only has to fetch half the number of bytes from main memory on cache misses for all those ptrs. It still has use of all the instructions of the Athlon64 instruction set, they work perfectly fine using 32 bit ptrs. Using 32 bit ptrs limits how much memory can be addressed by any individual program. If the OS is also 32 bit then it limits how much memory the OS can handle. If your machine main memory can entirely be addressed by 32 bits, then you do not need 64 bit addressing and will only get slower execution due to wasting cache space storing 0's. )

As these things always come back to bite ME, I would hope for more than guessing. That is why I mentioned testing this on various versions of older and modern windows. I know the current SDL version released with the binary works on most systems. You could tell me what you have tested and what version of Windows it worked upon. Given enough reports like that I would have something to support that version. Does it depend upon anything on the system, that might be missing on some other user's machine? That would be a serious problem as this binary explicitly supports older windows machines. This is NOT one of those newer-windows machine support only games where they do not want to hear about it if you are more than 3 months back from the bleeding edge.

This is why I have for years maintained that users should install a good version of SDL for their system, and NOT install default SDL libraries that come with games. I mean a system install, not just copying to the game directory. For most systems !!!, you can do better than that SDL library dll we supply in the download. Only you know what hardware and what compatibility you actually have, and SDL is a hardware interface library. Also, I develop on Linux, and do NOT know know modern windows. I cannot test SDL versions on windows. I do not remember if I ever was able to find an adequate SDL2 for my WinXP. (I will again reject any nascent suggestion (from the only Windows supporters) that I am supposed to get a modern Windows machine and give Windows users preferential support just because there are more of them. I am a Linux developer. I will support the Windows port to the best I can do given the hardware I actually have. I have no wish to retrain to support Windows better as I am overloaded with Linux projects already. I added two more this year alone, and another one is taking a whole lot of time and I am trying to not get dragged in.) Given that README, I would not know the primary from the alternate. The SDL_mixer 1.2.8 source that I have, has mikmod. It does have dynamic_MP3, and dynamic_OGG files, and I do not know why those do not work to find the existing support libraries. That is the Linux version, as I would have to fire up a stored WinXP machine to examine the Win version. I cannot debug everything, do not have the time. How likely is it that version 1.2.12 of the SDL mixer would be runnable on most systems ? Where did you get that ? To publish it on our site, I have to get it from the source. I am thinking that it would be possible to provide an alternate more advanced SDL library too. Of course some windows users are going to complain that it is too complicated, they want a single file with exactly everything that supports their system.

As I thought, SDL 1 can handle MP3 and OGG, but you have to compile that option in, and have the support libraries. If this was included in the default SDL builds, then everyone using it would be forced to install those libraries too. SDL 2 is must have enabled these by defaujlt, which is why MP3 works with the SDL 2 version. From the SDL mixer 1.2 README The mixer can currently load Microsoft WAVE files and Creative Labs VOC files as audio samples, and can load MIDI files via Timidity and the following music formats via MikMod: .MOD .S3M .IT .XM. It can load Ogg Vorbis streams as music if built with Ogg Vorbis or Tremor libraries, and finally it can load MP3 music using the SMPEG or libmad libraries. Tremor decoding is disabled by default; you can enable it by passing --enable-music-ogg-tremor to configure, or by defining OGG_MUSIC and OGG_USE_TREMOR. libmad decoding is disabled by default; you can enable it by passing --enable-music-mp3-mad to configure, or by defining MP3_MAD_MUSIC

I am expecting that it never did work with SDL 1. The SDL 1 DoomLegacy code does examine the mixer for which music decoders it supports (Mix_GetMusicDecoder), so it is possible that SDL 1 could handle MP3 and OGG. When I found out that there was MP3 in phobiata, I fixed the DoomLegacy code to support it properly. There was existing code that handled MP3 and OGG, but needed work such as menu controls and updating to SDL. Because the support for MP3 and OGG is in the backend (FMOD, SDL), the DoomLegacy code itself does not reveal much itself. The FMOD support code is still in there. The same music support code is there regardless of which backend it is compiled with.

Thank you, I will look at the Eureka source. I thought kb1 was creating a master list of used codes, but I have not heard from him for a while. --- Range --- Which codes are used, and which codes are available for expansion. I do not care about what they actually do, I just want to find unused ones.

Is there some handy reference of the used ranges for: - linedefs - wad thing codes - dehacked and BEX extensions Previously, there was a discussion of Doom extensions, that except for some discussion of non-support for any idea from any other group, pretty much got nowhere. As usual, each group just goes off an does what each group intended. I want to avoid creating any additional conflicts.

The bundled SDL is an older version, most compatible with all the versions of Win that it might be run upon. You should be able to find a better version of the SDL mixer. I remember one report of someone fixing music problems with a new SDL version. Due to all the complaints from Windows users, that they want installation dumbed-down like other games, I expect that improving the SDL bundled version would also cause problems and increase the complaints. Doom involves so many varied improvements, and so many system options are involved, that it is not practical to treat DoomLegacy install as a single monolithic product.

Again. OGG is handled by the SDL library. There is no code in DoomLegacy that converts MP3 or OGG. SDL allows music to be submitted in these formats, and SDL autodetects which it is. You do not state which OS, and which SDL you are using. That information is the most important thing in this problem. OGG and MP3 may not work without using SDL2. If you are using an older WIN, then you might not be able to get an SDL2 for it. On SDL it might be a compile option. I have not found out and as that involves digging into SDL source code, it may not happen anytime soon, as there is little chance of fixing SDL broken-ness. Too much happening right now, as other free program projects also want my time. SDL2 has its broken-ness too. In spite of explicitly supporting various music synth, it defaults to just using FluidSynth, and includes FluidSynth in the the SDL code. This has made using any other synth with SDL2 impossible, and I have not discovered how to work around it. Patching SDL2 seems to be the only way. I would like to find a way to know the capability of a candidate SDL library, without having to install and test it the hard way. I think that the SDL compile detects and has some options. Compiling a custom library binary on your system with all options selected may get dramatically different behavior. I only have an old XP system for testing windows. For other windows products, which version of SDL you use can affect how well it works. I have always held, that in spite of the fact that DoomLegacy includes a SDL binary, you may and probably will get better behavior using an SDL binary that is selected for your OS version. These may have fixes for system problems and the SDL mixer has been notable in that regards.

On my Linux system, a "strings" examine of the SDL_mixer library shows that SDL2_mixer has the string "mpg123", but the SDL_mixer library does not have that string. This may have been an option that was not selected during the compile of the mixer. Or that SDL1 mixer never had it at all, and the developers of phobiata were using some windows port hack to play mp3. There is some strange stuff in the WIN port of DoomLegacy. No one uses the WIN port anymore as it might need Win98 or something that old.

I tried mp3 music on Linux and it failed there too. This will take a while to diagnose why SDL cannot play mp3 now. Use the -v flag (verbose) to diagnose on your system. Mine reports that it has OGG and FLUIDSYNTH, but not MP3. This means that SDL does not have access to a MP3 player that it can use. This is completely dependent upon SDL having found an MP3 player during DoomLegacy initialization. We are both probably running newer OS than was being used in the last debugging of mp3. Who knows what they broke this time. I am making some changes, but they show that SDL does not have a MP3 player. I do not know why as there are several available. Probably some support library issue in SDL, or they did something like drop mp3 support (you never know). Do not change the lump names as DoomLegacy changes to use the mp3 lump names when it detects that SDL can play mp3. ---- On Linux, It "seems" to want library "mpg123" to play mp3 files. I have that library installed, and SDL still returns flags that it cannot play mp3. I have been using SDL. There is the option to try the SDL2 version of DoomLegacy. On Windows you can use any newer version of SDL. You are not limited to the SDL shipped with DoomLegacy. Cannot use SDL2 with the SDL version of DoomLegacy though. --- An older SDL2 doomlegacy binary I had worked, and did play the mp3 on this system. --- A new SDL2 compile of the latest DoomLegacy (1.48.15 work in progress) does play the mp3. It must be the SDL library. I know that phobiata was originally written for SDL and at one time it did work on SDL1. I doubt they support SDL1 any more and that is probably why the mp3 has gone broken on it. I will put this on my TODO list. Submit a bug report, would not hurt, as a reminder.

DoomLegacy feature wads. These are the names as I have them, which may be slightly different. DoomLegacy_3ddemo.wad Phobiata.wad -- the classic, torches, bridges, fireflies hth2.wad -- very large scale story wad Twilight -- commando ops 3D_Horror.wad DSV4 nimrod -- OK, but was never sure what features it was using vacuity.wad -- Jive, sci-fi, bridges, 3d floors, medium size and tough icerial2 Unholy Realms (ur) - bridges, complex mech,, text says Prboom compatible Nocturnus -- DoomLegacy bridges, give yourself some armor at starting sekkusu -- sci-fi-ish looking, 3d floors OldOrder - a BigAls wad, weird, cannot remember any features it uses, but requires DL spone2.wad -- 3d floors CyberArena3.wad -- coop, lots of cyberdemons Toxic_Pit.wad -- deathmatch wethbewe -- deathmatch sleeper.wad -- deathmatch bspeek.wad -- Blake Stone TC -- Not sure about many of these as FORCEKZ1.WAD Bishop.wad Compound.wad mummy1.wad mummyDM1.wad SewagePlant.wad h47/Slaught/Home.wad lolly.wad lplant.wad -- BigAls wads, water master.wad warzone.wad -- large war, cannot remember any features used andy/ * -- a series of simple wads using DoomLegacy features mystic/* -- a series of wads newboxe.wad -- boxing, in a ring football.wad -- sort of looked like football, but did not really work Leprechn -- support wad, very weird maxskin -- lots of skins smiley.wad -- weird noises, support wad ChexQuest ChexQuest - newmaps.wad -- 3d floors, fireflies ------- Blasphemer palette is Heretic, which is incompatible with Doom palette (in a colorful way). Selecting "-game heretic" and it will change to the Heretic palette scheme. You can use "-file doom2.wad" and it will be doom with the weird colors, and wrong weapons.

That is DoomLegacy 1.41, which is from before when I started using DoomLegacy, 24 years ago. Most any system that could run that, could also run the lastest 1.48.14 version. We have not changed compatibility requirements. I think there have been something like 1000 patches to the code since that version, some of them serious bug fixes. One of the serious fixes was rewriting the memory allocation, eliminating memory allocation errors and segfaults. The latest DoomLegacy binary (1.48.14) is compiled using Mingw on a WinXP system. Before that it was compiled on a Win98 system. It sill has support compiling on Win98, and DOS. Newer DoomLegacy have automatic memory growth, and does not require telling it how much RAM you have anymore. It cannot run Doom3. What are you running, DOS5, FreeDOS, or something else.

In the last year, DoomLegacy had some DOS support from one of the users. We included patches from that user into the source code. Do not know how far they got as they have not replied since. These were mostly typos in the DOS port software that had accumulated due to changes in the port interface over the years. The DOS port support is still in DoomLegacy, and may be gotten to work. I would have tested it by now, but for time, and having lost my DOS partition when last upgrading this machine. Over the years, all patches to the port software, have also been patched in the DOS port software too. I just have not been able to run it to test for bugs.