in the first place, i'd like to thank the creators of this DOS wrapper 😀
and in the second places, comes disgrace...
Got a HUGE mess with Carmageddon 1 and SP
Turns out I try that Glidos thing and worked (merely, got buggy as hell), but the game crashed after a few seconds, like 30 after starting a race, not to mention that the Intro movie freezed, and the menus were f**** up.
So then, I get to try dgvodoo, and then.... nothing happens, a window pops up saying that the server isnt present.
After setting dgvodoo in C:\Windows\system, this magic message appears, a quarter of second before the window shuts (and thanks to my ninja-like reflexes that allowed me to sc this thing...)
the worst part here is: from that moment on, the 3dfx exe got always like this, it never mentioned anything about that server being absent.
Splat Pack got like that too.
*Apart from all this mess, i can't run the server mode thing, because this appears 😖
(and thanks to my ninja-like reflexes that allowed me to sc this thing...)
Well, dgvoodoo for DOS can work in two modes:
- VDD mode: don't care what it stands for, the point is, in this mode it's enough to have and use glide2x.ovl and glide2x.dll (and dgVesa if u use that) in a copy-and-play fashion, as if you had drivers for a real 3dfx card, without any additional actions (apart from potential configing with dgvoodoosetup). However ATI drivers couldn't always handle this line-up and pulled the OS into blue death (that was about 2 years ago). So, I was forced to implement a more standard and safe working mode:
- Server mode: in this case, you have to run dgvoodoo.exe in order to use vesa and glide emulation, as the emulated rendering is separated into a discrete process, and the Dos's thread and that process communicates with each other in client-server way.
Required mode can be chosen in dgVoodoosetup (DOS tab, see 'Working in VDD mode'). AFAIR the default is server mode, that's why you couldn't use the wrapper.
BTW there are a few problems with Carma1 as for (unfixable) rendering artifacts, they were discussed earlier (1-2 years ago 😁 ) in this thread.
I haven't tried dgvoodoo with Blood MapEdit, but dgVesa has support only for modes with linearly mapped memory (apart from VESA-banking). So that, all 16 color modes (4 bit, 10h, 11h, 12h and even 8 bit x-mode 13h) are out of its scope, unfortunately.
I didn't take it as a big problem, as there weren't many games/apps using those modes, I thought. If requesting of one of those modes is detected, dgVesa passes the request to the OS to use their native emulation. So it's an unworkaroundable problem on Vista, because its new display model doesn't allow any legacy VGA functionality. 🙁
However, in theory dgVesa could be improved to be able to handle more comprehensive VGA-register emulation like DosBox does, but it's not the case with 1.50... 😖
Restoring use of dgVoodoo - Tomb Raider 1 under Windows Vista
I finally came up with a working solution to the problem of sapucdex (hence dgVoodoo too) failing under Windows Vista.
Windows NT/2000/XP's default MSCDEXNT emulation for cdaudio does not support many functions that DOS programs (like Tomb Raider 1) require, hence Windows NT and later do not route CD commands to Windows, and CD audio will not be played.
Sapucdex was made as MSCDEXNT replacement to route the correct DOS commands from the game to Windows' sound system.
Enter Windows Vista and Sapucdex itself, the replacement, needs replacement, because it can't route the cdrom commands, like play, pause, stop etc., from DOS (i.e. the game) to Windows and again it falls back to no chance to play cdaudio tracks music.
Ssdh which is going to be discussed here in its turn is aimed to restore this DOS cd audio playing capability lost in the Vista era.
By way of a quick account :
it necessarily resorts to using MCI functionality
(Windows Multimedia Media Control Interface : http://msdn.microsoft.com/en-us/library/ms704979)
to make for needed cdrom access, which previously Sapucdex used to accomplish via the so called ioctl_cdrom structures (for input/output control), now apparently to be considered as deprecated, according to MSDN's own docs
e.g. : Obsolete, beginning with the [sic!] Windows Vista. Do not use this IOCTL to develop drivers in Windows Vista
as per http://msdn.microsoft.com/en-us/library/ms804546.aspx.
Now since sapucdex used to be taken advantage of by dgVoodoo, the free Glide wrapper by Dege who together with VDMSound would let WinXP machines to run smoothly TR1 (nicer looking Glide version) with music and everything, under Vista dgVoodoo had now become practically useless for want of music reproduction, and prone to extinction, even as visual features are still viable,
so the new MSCDEXNT replacement's replacement regains the chance to use dgVoodoo (with VDMSound and possibly via the TR1 Advanced Installer too) to be able to play Tomb Raider 1 and 1 Gold aka Unfinished Business under Vista as well
WHAT CAN THIS PROGRAM DO FOR YOU
Ask not what this program can do for you—-ask what you can do for this program.
You can provide for it and give it a safe haven, nourishment and a fair chance to exert its full-fledged potential, IOW :
what is your Windows version?
1.1 WINDOWS XP
(successfully tested under XP Home SP3)
if it ain't broke...
actually sapucdex/VDMSound/dgVoodoo all run smoothly under XP. Me, I just had to try ssdh out all the same, and finally see it work, but why should you bother to try too ? Sometimes I really don't understand you.
If you do insist, just drop both ssdh.exe & ssdh.dll into the folder where sapucdex exe/dll have been dwelling smug for years, usually c:\tombraid, and assuming VDMSound, dgVoodoo and Tomb Raider are alreay installed preferably via the TRAdvancedInstaller, now you have 2 ways to run TR1/TR1 Gold w/ssdh, a hard and an easy one
the hard one first
at the prompt in C:\tombraid , type :
if it's TR1 Gold replace tomb with tombub,
or (I know, this ought to be 184.108.40.206 now 😜 ) you can make a plain tomb.bat file ot tombub.bat doing the same without having to type it all every time.
the easy one is just via your good old VDMSound shortcut, that .vlp file with the TR1 icon, you'll have to right click, go to properties tab-> VDMS Launchpad Advanced Settings-> DOS Environment-> AUTOEXEC.BAT-> Additional options :
where it reads, or should read, c:\tombraid\sapucdex.exe let it be aware it's got to be c:\tombraid\ssdh.exe, save and you're done.
1.2 WINDOWS VISTA
(successfully tested under Vista Home 32bit SP1)
now that's what this is all about.
First of all, a previous if incomplete short primer I had already written here
exactly in this thread on page 15, message dating from 2007-11-22 @ 05:16 pm
Contrary to earlier reports and to what is still to be read all around the net, the assumption appears to be made up out of thin air that VDMSound and dgVoodoo won't work anymore under Vista, period : if they are installed, you run them at the command line and the dreadable no full screen crash won't pop up
copy ssdh.exe and ssdh.dll to c:\tombraid
move the relevant dll files for glide (glide2x.dll) and ssdh (ssdh.dll) from c:\tombraid to \windows\system32 folder
copy the vdmsound one (vddloader.dll) from c:\program files\vdmsound to \windows\system32 folder, so one copy of vddloader.dll stays in c:\program files\vdmsound, while presumably in c:\tombraid there should never have been one vddloader.dll file anyway (thanks Chug a Bug!)
(ssdh.exe can safely stay in \tombraid)
run dgVoodoosetup to let it look up the right path for glide2x.dll (dos tab)
and in the vesa tab enable "Use built in VESA support".
then you can get back to 1.1.1 up here (a-ha! I knew I'd get you there, confess to it, you had already forgotten about it, or never even read that didn't you) and follow through except....
you have no 1.1.2-like option here or it's all going to cave in on you and you'll see, if not the fatal BSOD, all the darn thing crash and burn.
So do me a favour and stick with 1.1.1.
made a windows installer for this
to be found here
Use it and kindly report, either if it works or if it doesn't flop in the least for you.
Come back with any other kind of response and the consequences of that could be disastrous (Doc Emmett Brown).
Particularly for me.
Don't ever lesnerize.
this version of ssdh.dll has logging messages enabled which means that
each time you run it it creates a log file, either called c:\sapucdex.log or c:\tombraid\ssdh.log
depending on whether the dll file was built by me before or after... I noticed I'd been dumb enough to forget to edit the relevant line in the code
since it can quickly grow to eat up hundreds of KB if you play frequently and/or for a long time pretty soon I'll recompile, and link to, a new one without the log file making, which after all only serves a testing purpose
if you don't want any log files hanging around, you can delete c:\sapucdex.log, or c:\tombraid\ssdh.log, right away
or take a look at it
an interesting info comes from the recurring couplets of
23:41:38.292 DEVICE_STATUS, STATUS = 0300, CF = 0
23:41:38.307 AUDIO_Q_CHANNEL_INFO, STATUS = 0300, CF = 0
23:41:42.260 DEVICE_S […] Show full quote
23:41:38.292 DEVICE_STATUS, STATUS = 0300, CF = 0
23:41:38.307 AUDIO_Q_CHANNEL_INFO, STATUS = 0300, CF = 0
23:41:42.260 DEVICE_STATUS, STATUS = 0300, CF = 0
23:41:42.260 AUDIO_Q_CHANNEL_INFO, STATUS = 0300, CF = 0
about every 3.9 seconds these check the status and CF parameters
CF (carry flag) should be = 0
while 1 means error
and status ought to equate = 0300, that is 0300h = 0200h (busy) + 0100h (done)
while all values like 81xx (8100 and above) e.g.: 81ADh spell trouble
WARNING : Discardable matters from here on.
WHAT'S IN A NAME? THAT WHICH WE CALL A CDROM
damncdex.dll, that's what I should have called it!
As my old and sagging Visual C++ version is about 0% Vista-compliant, I had to become your human macro :
insert my shrewd code manipulations, compile and test with my XP machine, if it's any good, quick jump to the usb flash drive, flip it to the other PC, the Vista machine...
what's going on ?
oh no please, not another deafening "sound of silence" rerun, I only ask for some music to play.
Now testing is over for me. Then again, damncdex.dll as I learned could constitute a pretty serious capital offense in 87 countries around the world.
I then thought of It's a small step for mankind--a giant leap for a man.dll
but no, it dawned on me this might be not fully compliant with some systems using the filename 8.3 convention, what's more it could have turned by design into a ITSASM~1.dll, and whoa, ssdh.c is no .ASM file, not at all : ssdh.asm is, but ssdh.c is a C file isn't it (<- if that hasn't set you ROFL, you just have no heart, I say, and I'll quit playing with you)
I thought mci_cdex.dll was just too true to be good.
In the end I felt it had to be ssdh. That's it.
Ask what that ssdh thing f*****g stand for finally? Man, that's so curious of you.
Why, that's the acronym from: "so sagt die Hex", it's German, a quotation from Goethe's Faust, Part 1, it means: so says the witch
(which old witch? The wicked witch!), from the Witch’s Kitchen mise-en-scène, you know, the Magic Square evocation... http://mathsforeurope.digibel.be/Magic2.htm (halfway through)
have no clue what I'm talking about ? And you call that a life which you are living!
Anyway the big, dull deal about it is of course die Hex (German: witch) vs. the hex(adecimal) numbers. Dislike it ? Pal, are you hard to please!
Other than that, soSagtDieHex is an alternate nick of mine that I love and I've been using lately, and I wish so bad I could ditch my old gidierre one, I've grown so fed up with by now, for it...
You run it 666 times and it'll land you on top of the mountains of Ararat.
A LIDDLE RINGERS... A RING-A-£|@#... A RIDDLE LINGERS
Now that all is said and done (until next blue screen of death) and my tears subside, a riddle keeps haunting me :
will this stuff still work under future OS versions, like Windows 7+ ? or under 7up ?
Well, uhm... "Have you guessed the riddle yet?" the Hatter said, turning to Alice again.
"No, I give it up," Alice replied. "What's the answer?"
"I haven't the slightest idea," said the Hatter.
"Nor I," said the March Hare.
Alice sighed wearily. "I think you might do something better with the time," she said, "than wasting it in asking riddles that have no answers."
come enjoy the new feature : The Cdex's Chainsaw Massacre http://www.imdb.com/title/tt0324216/
(only this time unfortunately Jessica Biel won't be in it due to alleged previous commitments)
or, the havoc I brought into sapucdex source code and how it oddly seems to have delivered.
Originally, this sapucdex revamping was supposed to be a shameless monkey's stea.. oops, mimicking of dosbox source code, in the end it became a shameless monkey's mimicking of dosbox source code instead.
Am I flipping out ? Not really.
You know, dosbox source is a mine you can go and fetch many things from,
there's cdrom access via SDL routines (cdrom.cpp) and other alternate ways to make it (like cdrom_ioctl_win32.cpp recently refurbished in cvs, thanks wd) whom I examined all out searching for inspiration.
Sapucdex uses IOCTL routines which are mostly marked by ioctl structure calls deprecated as obsolete under Windows Vista, so it's assumed that's the reason why it stopped working when Windows 6 came forth.
My first idea was to replace those ioctl calls with other ones using whenever possible SDL routines
see e.g. http://www.libsdl.org/cgi/docwiki.cgi/SDL_CDOpen and surrounding webpages
but I found huge problems mostly right at the initialization step
finally I gave up on SDL, my last and final venture into it was trying to encapsulate SDL implementation between a shut and reopen ioctl operation in DevPlayAudio()
going at it between one call to
and then afer invoking and closing sdl, one to
to avoid clogging the whole sapu proceedings.
I found the best way to effectively save/restore drive pointer stuff was doing this
which actually shuts/reopens the drive, then implementing sdl stuff : nothing.
Out of this predicament I tried to break loose by recurring to MCI calls and it seems it has worked.
I still kept sapucdex general framework to ensure all Int 2F/AX=1510h (SEND DEVICE DRIVER REQUEST) interception performed by it was retained whenever feasible, mostly editing the Open drive, Play and Stop functions.
In StopAudio() at any rate the Pause command is also handled.
The Seek, ResumeAudio and GetAudioStatus were on the contrary less edited than brutally commented out by me, not without a perplexed reflection on the scant pros and multiple cons of such a desperate move.
Mostly DevPlayAudio() and DevStopAudio() where hacked until almost only their empty outline stayed.
(Don't know whether this could be defined a source wrap. To me, it looks less like a wrap than a rip-off.)
All activity being taken care of by MCI counterparts, the main hindrance was the obligation to zero in to fine-tuning the coexistence of ioctl and mci implementations side by side so to speak within the same program, which is precisely the reason for my abandoning the sdl option.
Much more could be debated, but in order to do so I'd have to begin posting substantial portions of the code here, which I'll only be sure to do if someone cares to view and discuss with me, and possibly teach me how to improve things further.
Last edited by gidierre on 2009-06-20, 23:28. Edited 8 times in total.
We often forgive those who bore us, but we cannot forgive those whom we bore. (La Rochefoucauld)
Carmageddon/Splat Pack buggies, for what they're worth 😎
1. The windshield on Die Anna's car (Hawk) from Carmageddon 1 is no longer reflective but matted gray. Interesting enough, this doesn't happen in "Splat Pack", the official addon.
2. The bloody hand pointer turns into a glitchy square in "Action Replay" mode (keypad's "Enter")
3. The mirror ("M" key) from the cockpit view ("C" key) is missing, only the plastic framework is visible. I haven't played Carmageddon with a real Voodoo card since 1999 so this might as well be a limitation of the actual 3dfx executable. I can't remember and I can't tell for sure, but I'm reporting it "just in case" 😀
4. No bilinear filtering is being applied to the menus whatsoever, it all looks pixelated to hell.
5. All I can see in that menu you're prompted to at end of the race which gives you a full 3D view of the demolished cars, is my car's tires! Everything else seems to be invisible.
6. Sprites get UGLY black outlines when "Force Bilinear Filtering" is checked. The correct/original way for displaying these sprites would be bilinear filtering alone for "softening" the whole sprite without sharpening it's edges.
. 3dfx executable for both "Carmageddon" and the "Splat Pack addon: CARMAV.EXE 1.32 MB (1,386,650 bytes)
dgVoodoo v1.50 Beta2
Windows XP Professional SP3
Intel Pentium 4 3.0ghz
1024mb DDR RAM
NVIDIA Geforce 6200 256mb
OS, Forceware drivers, DirectX and everything else up to date.
Thanks dege for developing this excellent glide wrapper. Carmageddon fans owe you big time.
Yes, I tried the POD_P4AMD_Patcher.exe. But when I run it, it says: File state: Unknown file. I've the POD version that came with the OEM PC.
When I get the messed up screen, I am able to press Alt+Enter. Then I get POD in a windowed screen, and it is not messed up anymore. But then I have another problem: it runs way too fast! Is there something to solve this?
My POD Gold I have the dgVoodoo setting under Glide as "Always wait for at least one vertical sync" ticked on. I think that slowed it down for me. Otherwise set your refresh rate to 60fps and vsync locked on in your graphics card settings, see if that helps.
My PC spec: Win10 64bit, i7-4970K (not overclocked), KFA2 GeForce RTX 2070 SUPER, Creative Soundblaster ZXr, 16GB RAM, Asus Z97-A motherboard, NZXT 410 case, ROG Swift GSYNC monitor
"Always wait for at least one vertical sync" was already ticked on. I tried setting the refresh rate to 60fps, but that option is greyed out in the dgVoodoo settings under Glide. I did set the refresh rate to 60 fps in Catalyst Control Center and set "Wait for vertical refresh" to "Always on". But POD still runs way to fast when I Alt-Enter. Before Alt-Entering, so when the screen is messed up, POD does run on the normal speed, so NOT too fast. For some reaseon, I doubt if dgVoodooSetup.exe really does something, because whatever changes I make in that program, I can't notice any differences at all when running the game.
Some more info: I'm running Windows 7 32-bits and my graphicscard is a ATI Radeon HD 2400XT. My CPU: Intel Pentium 4 540 @ 3.20GHz.
I also have tried to play POD on my laptop (Lenovo ThinkPad t60p) with Windows 7 32-bits and there it runs perfectly. But I want it to work on this desktop as well 😒
I was trying to play Carmageddon 1 on XP with VDMSound and using dgvoodoo 1.40 and 1.50beta. When I'm starting a new race after choosing position, game freezes, screen goes black. I can only reset PC. I have Radeon 9700 and newest catalyst 8.3. Can you help me?
I'm having the same problem on a Radeon HD4850 with Catalyst 9.10, although I can force close the program with the task manager. Anybody got any ideas?
I've tried using the log version of dgVoodoo 1.40+ and it floods the .log file with this error:
1 Fatal error: ProcessExecBuffer: Invalid function code in communication with DOS! DLL and OVL are probably not compatible!!
And when I say flood, I mean FLOOD. In a couple of seconds the .log file has reached several megabytes. I've tried re-extracting the .dll and the .ovl from both the log and normal version. I run everything straight from the game folder. I've even tried using 'Display driver: RGB Emulation' to rule out my graphics adapter.