emailking

Took all day, but I just installed hundreds of windows updates and something did it because it works now. So I'm good.

Ok I tried it. It made no difference. I get the exact same error message. (I guess all that what I did really proves is that whatever is going wrong, it goes wrong after fluidsynth loads.) Any ideas?

Hi, entryway. Thanks for responding to my post. I tried the version you just posted. Unfortunately, it did not work. I got the same error message. Here is a screenshot of the error message: http://oi49.tinypic.com/ekpxxt.jpg I think it may have something to do with libfluidsynth.dll. If I delete all of the other DLLs and leave libfluidsynth.dll, I get the same error message. But if I delete libfluidsynth.dll, it jsut says that it couldn't find libfluidsynth.dll. I have also tried versions 2.5.1.0, 2.5.1.1, 2.5.1.3, and 2.5.1.4 test. All of them get the exact same error message that is in the screenshot above. 2.5.0.8 is the most recent version that runs.

I can't get this to run on a windox xp laptop I just bought. (includes both glboom-plus and prboom-plus) 2.5.1.0, 2.5.1.1, 2.5.1.3, and 2.5.1.4 test do not launch. Not even the launcher will run. I just get an error that the application failed to initialize and then a memory address. Going back, 2.5.0.8 is the first version that launches, and it appears to work properly. All versions of prboom-plus launch and run on my old win xp machine (that is much slower and has a small screen so I don't want to use it). Any ideas? I'm hoping there's a solution because I bought this laptop specifically to watch doom demos. I went with xp because in the last few months, prboom-plus kept giving a blue screen of death randomly on my windows 7 machine, forcing me to do a lengthy system restore to get the machine working again. I finally wiped the machine and tried running with it bare (no programs installed, no windows updates, etc.) and I had the same problem. I figured it must be a machine specific problem since no one else seems to have this issue. So I decided just to buy a win xp machine for doom, since it was cheap and I figured that would have no problems.

The way it reads, there is certainly nothing to imply that any monster must be dead at the exit. However the way it reads is apparently not what the writer of those words meant by them, nor is it the way most people have played max/fast/tyson. With the exception of certain difficult/impossible to reach monsters, all monsters (save lost souls) that are present at the beginning of the level must be dead at the end.

Thank you for the responses. To be honest, I don't really understand the explanation. Is what you're saying that the game state is updated 35 times a second, but the hud is calculated 1000 times a second (including every 0.01 seconds), and so there is a remainder problem...because 35 does not divide evenly into 100? I can see how that would make a mismatch. I still don't understand why the display time at the exit can be different from one run to the next, when using the prboom-plus executable. Why is that not repeatable? Ok separate question. I used the launcher to set the registry to call glboom-plus and use -auto when I double click a demo. If I double click a demo that's in my doom directory, it uses timidity like I want it to. But if I double click a demo in a zip file, it doesn't use timidity and I have to suffer the pause every time the music loops. I assume it has something to do with the active directory. Is there a way I can fix this? Many thanks.

I noticed something odd when I played blob1024's max run of map 22 of community chest 3. He hit the exit at 3:50.97, but the final time came up as 3:51 on the stats screen. I was able to reproduce this repeatedly. I had been using glboom-plus. Then I tried with prboom-plus, and the results became even more bizarre. Half the time he hits the exit at 3:50.97 and half the time at 3:51.00. It is seemingly random which number it is. Regardless, the time on the stats screen is always 3:51. I tried to replicate this 50/50 behavior in glboom-plus but couldn't. When I use glboom-plus, he *always* hits the exist at 3:50.97 (stats screen always says 3:51 though) and never at 3:51.00. Here are the exact command lines I was using to test. glboom-plus -file cchest3.wad -playdemo cch3-22-3-51 -skipsec -12 prboom-plus -file cchest3.wad -playdemo cch3-22-3-51 -skipsec -12 Is there an explanation for this? Here is the link to the post with the demo: http://www.doomworld.com/vb/showthread.php?postid=962071#post962071

Apologies for the possibly dumb question, but is the music supposed to change from map01's music to map31's music when you cross the farthestmost set of columns? Because that happens to me every time.

Our cc2_m24fs have the same size but are actually different binary files according to winmerge. I do not desynch when I use yours. I don't know how I have the "wrong" fix wad (which does fix the door that won't open) but apparently there's a secret door that won't open in mine but does in yours. I said it desynched at 29:45 because I thought a Mancubus was out of place and caused the obvious desynching 20 sec later, but apparently you just missed it. ;) But anyway, problem solved. Thanks! :)

The HMP one desyncs for me too. (Haven't figured out where, bu 40 seconds before it's supposed to be over the marine is wandering aimlessly near the start.) We match on cchest2.wad. What's the bytage on your fix wad? Maybe that's different somehow. I have 2406553. I only used the 2505 executable but the next thing I'll try will be a clean install from the zip in a separate directory. Maybe some other DLL is the problem.

Thank you for the demos. This is my favorite cc map. Does the uv demo desync for you when you play it back? For me it desynchs around 29:45. Here's the command line I used: glboom-plus -iwad doom2.wad -file cchest2.wad cc2_m24f.wad -playdemo c224-uv I checked and it does detect complevel 9. I'm using the test version of prboom+. I also tried with 2.5.0.5 which the text says you recorded with. Same deal. Forcing complevel 9 doesn't change anything. Did I miss something?

Excuse the ignorance here, but I was wondering why does the invulnerability look so different on this wad (longdays)? Like...it looks more as though everything turned black and white, whereas with invulnerability it normally looks like light and dark reverse.

So it's a COLORMAP then? I wonder why the author did that.

It can't be that because if I go to level 2 (just the normal Underhalls) and use invuln there it looks *very* different from what I get if I use invuln on level 2 with just the iwad and no longdays loaded. Here are pics showing the difference. normal: http://i50.tinypic.com/142fx2t.jpg longdays loaded: http://i46.tinypic.com/20glfh0.jpg

Got it. Thanks.

Hi. Where did you get the wad for this? I got it from this link: http://www.doomworld.com/idgames/index.php?id=10639 But your demo desynchs in level 18, in complevel 2, with the version of prboom-plus you used.

[/B] Have you tried using -nomusic instead? -nomusic used to mute everything on Vista/Win7, but that's fixed now. I would have thought the same fix would fix your issue, but you said you updated. I would make sure you have the latest stuff. This is an SDL bug that affects Vista and Win7. If you have a multi-core CPU try setting the process affinity mask (in the config) to a different cpu. Setting it to 0 instead of 1 seems to help for me (hanging not as bad), though you will risk a crash. But it doesn't crash very often.

Ok and I updated and here's what's fixed: 1. -nomusic now only turns off music, not all sound 2. Sound and music seem to work fine on logdays.wad Thank you very much for those fixes! Unfortunately, there is still a hang every time the music loops. I don't know if this was intended to fix that as well. Also, I just noticed something which is probably unrelated. If I do: prboom-plus -iwad doom2.wad -warp xx or prboom-plus -iwad doom2.wad -skill x The program crashes immediately (the typical exit on signal error message). I don't remember that ever happening before. Just the presence of the -skill or -warp commands seems to crash it for some reason. I'm using the current test version now, but this also happens on a 2.5.0.5 build from October. (It's dated 10/24/2009 on my machine...I don't know what build it started to happen in though.)

Awesome, thanks! I can see the video now.

Nope, I hear nothing. I put all the files in the same folder. Let me know if I was supposed to do something else. I have the latest audio drivers. It's not Realtek. It's "SigmaTel High Definition Audio CODEC" whatever the hell that is. It's the native sound card & drivers to my dell laptop, and I have ensured the drivers are the most up to date that they have.

Yeah, that's what I meant. Sorry, I thought it was just a sound file. Hence my confusion. Anyone know what codec I need to watch the video? I tried 2 computers and it just plays the sound. Or if it's simple enough to describe what the video depicts...

Hi, can you explain what you mean by that? I updated to the latest test versions of prboom+ and the SDL contained in the zip. I still have the music problems. I have SDL in the same folder as the executable. Win 7 Unltimate, 64 bit. Thanks!

And maybe it will work great, but reading something like this gives me pause before it's confirmed. http://www.theinquirer.net/inquirer/news/1051975/xp-mode-windows-scam

entryway, does your version of Windows 7 have XP mode? If so, can you see if you run into these problems when you run on XP mode? I've been hoping once I upgrade to windows 7 professional (or ultimate) this fall that these issues will go away at least in the XP mode.

entryway said: Does old SDL help? As far as I can tell, the problem is non-existent if you go back far enough. 2.2.6.19 seems to have no hanging issue for me. (The entire prboom+ package I mean, with all the SDL's that come with it.) 2.2.6.24 does have the problem. The music also hangs on re-loop in Chocolate doom.