Nevermind, seemed to be something to do with my user account. Running it as a different user fixes the problem.

Anyway.. Dege, you said about setting the timer value. I cannot see where this is set.

If I save the config to a text file i can see that the timer boosting period is 80 ms but there appears to be no way of changing this.

I have the same problem with carmageddon and would like to experiment finding the best timer value. How do I go about setting this?

Thanks.

This is how to change timer boost for Tomb Raider (for other games it should be similar, just use folder where your game is installed instead of tombraid):

I assume that your Windows is installed on C: drive and dgvoodoo files are situated in c:\tombraid folder). Run command line first, type in:

cd:\
press ENTER
cd tombraid
press ENTER
dgvoodoosetup $FirstFound$:0 /platform:dos /timerboost:XY
press ENTER

XY is your desired value of timer boost. Changes are saved directly into glide2.dll. This is the only way to change this value in current version of dgvoodoo, maybe in next version we'll see it in options window?

Thanks Zebuis!

It'd be cool if when you saved the config it saved as an ini file. That way settings could be easily changed.

Again, thanks. Going to check that out 😀

Ok, anything above 15ms and it does become shaky when going up hills, turning etc.

It exists even on 1ms. Just the lower the value the less noticeable it is. The game does run a little fast though. (Not sure if the physics is affected. Just the count down timer seems sped up slightly.

Dege, heres a description of the problem the best way I can explain it:
As you move, the car doesnt move smoothly. It's jerky but it's not to do with the framerate. It's not noticeable unless you turn or go up a hill (though changing timer boosting makes this almost un-noticable when going up a hill.) The car will move from the first position, into the next, but it will kinda go from the first to position, past the second potition and back to the second. So it say it was moving along this line.... A - B - C, starting from a it would jump to c then back to b, and this happens very quickly over a low number of frames (possible 1 frame per movement but i cant really tell.)

Hope this helps. Is this a problem with dgVoodoo or carmageddon itself?

Edit: This does not appear to happen with Glidos. But the framerate is nowhere near what it is on dgvoodoo.

Update (06/05/2006): It does happen in GliDOS the framerate just isn't high enough to notice it. It also happens using carma95.exe using software mode. So it's a problem with carmageddon itself. Seems that running the game at a higher resolution and/or higher framerate just makes it more noticeable. Lowering the timer boosting value does help. (Though speeds up the game clock.... but I cant tell if it speeds up the gameplay).

Hi degee, I just wanted to say thanks for this great program.
Finally after years I can play Tomb Raider 1 in its old glory again. I first tried Glidos, but somehow I got all kinds of graphical glitches (visible artifacts behind walls etc.) . But now with dgVoodoo finally everything is running OK and in addition it is free and without any logo. 😀

Also the color range looks much better compared the washed-out look in Glidos.
To be fair, the original Tomb Raider 3dfx on my Diamond Monster also had this kind of look with the original Gamma Setting, but the new colors seem more natural and compare better to the other games in the series.

So Tomb Raider never looked as good as now! Cheers again! 😉

... 😊 😐 Sorry for not responding at all..
Today I dusted dgvoodoo src and made myself do something with it. I put some development into it since 1.40, but never had a good mind to keenly deal with it. 😀 So, today I finally got it to a releasable beta state (I hope), otherwise I will never get rid of it. 😀
I've just uploaded it, but don't expect too much, as usual.

Hi Dege!
Nice to hear you are still there 😀

I've just tried 1.50beta with Tomb Raider and the gameplay is fine as usual. I've noticed one visual glitch - when using DX9 renderer I can see blinking icons of my taskbar during gameplay, it doesn't happen in DX7 renderer (Windows XP SP2, Athlon64, 6600GT, all drivers up to date).

Could you add to menu some options which currently are hidden: adjusting time booster and alpha reference for better graphics in Tomb Raider? They could be marked as Advanced Users' Options or similar to avoid misuse.

Thanks for your work! Keep it up! 😀

DX9!! Did you find any nice ways to handle writes to the front buffer?

I've noticed one visual glitch - when using DX9 renderer I can see blinking icons of my taskbar during gameplay, it doesn't happen in DX7 renderer

Indeed, it's a problem with DX9. It seems that GDI isn't shut down even during full screen rendering and overwrites areas that aren't covered by the application window (taskbar, message balloons popping up from the taskbar, toplevel windows, etc). Don't know what to do with it for the time being. 😒

Could you add to menu some options which currently are hidden: adjusting time booster and alpha reference for better graphics in Tomb Raider? They could be marked as Advanced Users' Options or similar to avoid misuse.

I was about to hide as many options as possible to improve the look&feel. 😀 But ok, changing the alpha-ref and timerboost values seems to be useful for many people, I'll try to expose it on the GUI in some way or other. 😀

DX9!! Did you find any nice ways to handle writes to the front buffer?

Unfortunately not. Actually, front buffer is totally unlockable (effectively) by default. There is the other way when all buffers are allocated and maintained by the wrapper but it requires an extra copy to the swapchain's backbuffer before ->Present (). In this way the front buffer is lockable, but always copied and "->Present()'ed out" when the changes are flushed. It's not too EFFICIENT method tough, especially with multiple locks per frame. (It's similar to DX7 windowed mode...). But there is the DX7 renderer in fullscr for heavy front buffer locks. 😀

(Edit: I mean efficient...)

I would really like to see [x] Force texture tiles option 😉

Edit:
Ah, yes, I see it now 😅
I must have missed it in readme, thanks dege. 😉

You can do that via the command line interface. Texturetiling has three mode: auto, disabled and forced. The GUI only toggles between auto/disabled. 😀

I had to use that method too, allocating the extra buffers and copying them before presenting. But games like Descent II were hopelessly slow if I presented on every unlock of the front buffer, so I ended up setting a flag and presenting on a timed callback. Doesn't really work very well.

I'm also suspicious that my texture loading code is slow. I was never certain how best it should be done.

I tried dynamic textures that I could lock directly (pretty certain that is NOT the way to do it).

I tried creating a surface in the system pool, which I could lock, and then using UpdateSurface to transfer the data to the texture.

And I tried D3DXLoadSurfaceFromMemory.

None of those methods seem to exactly zip along.

I had to use that method too, allocating the extra buffers and copying them before presenting. But games like Descent II were hopelessly slow if I presented on every unlock of the front buffer, so I ended up setting a flag and presenting on a timed callback. Doesn't really work very well.

Yes, it's slow. 🙁 I have a game demo (Test Drive Off-Road 2) which writes its in-game menu options directly to the front buffer, and those lock/unlock pairs couldn't even be closed up to one flush, so 7-8 front buffer flushes per frame is done there... It's terribly slow and ugly, but what else could be done in such a case? 🙁

I tried dynamic textures that I could lock directly (pretty certain that is NOT the way to do it).

Why is it pretty certain? 😕 I use dynamic textures (in default_pool) in dgv too in a locktexture-updatedata-unlocktexture way to use the most direct data uploading and avoid any extra copy that d3d runtime would do. 😀 One annoying thing is that all texture get lost when the device itself becomes lost, so recovering them is somewhat painful. I've built in an option to control what pool they are created in. If I create them simply in managed_pool then the d3d runtime will take care of them, but the price is you can only lock a sw mirror-buffer and d3d copies the data to the video memory when needed (transparently, so no need of UpdateSurface). Not that it would be so slow, to be frank, I didn't notice any performance loss in practice. 😀

D3DXLoadSurfaceFromMemory must use one (or similar) of those methods so I doubt it could be more efficient. But, I don't use D3DX since I wrote all needed data converting function previously.

Oh right. That interesting. I'll try it again then. I thought I read something that said you shouldn't create too many dynamic textures... something about creating one per size, and sharing them amongst all the texture drawing. That made me think they were a resource more limited that other types of texture. Thought I had trouble with failed intermittant failures of attempts to create them too.

Thanks for the tip. It does seem to work fine.

Hi boys, I'm from Italy so excuse me for my bad english. I'm not a programmer, just a fanatic Tomb Raider gamer and I want to share with you my personal experience about dgvoodoo (and glide wrappers in general).
I run XP sp2 on my old pc (PII 350 MMX, Diamond Viper V550, SoundBlaster Live!, 256 MB RAM). I started using v1.31 and everything was fine at first, except for the writings on the main menu (unreadable) and the brightness of the screen during gameplay, too high compared to the original. So I went looking for another glide wrapper and found eVoodoo:
http://evoodoo.emulation64.com/evdown.html
(I downloaded the version linked at the bottom of the page).
Without knowing what I was exactly doing, I replaced the original dgvoodoo's glide2.dll with the one found in evoodoo, added also glide3.dll from the latter (this one was useless to my purpose, as I discovered recently), and wow... now the graphics are exactly the same as the original, textures are perfect, I can even read the titles. Unfortunately (obviously, you'd say...) dgvoodoo notice the change, and dgvoodoosetup menus become greyed out. The weirdest thing of all is: eVoodoo alone won't work for Tomb Raider, it seems to be necessary some glide.owl (which of corse I took from dgvoodoo v1.31). The .owl libraries in the new versions of dgvoodoo don't do the same miracle, so I decided to ask directly to the author for his opinion.
By the way dgv 1.40+ and 1.50beta don't work for me.
I'd be ok with my workaround, if only I could take screenshots. But I can't!

Hi!

I started using v1.31 and everything was fine at first, except for the writings on the main menu (unreadable) and the brightness of the screen during gameplay, too high compared to the original.

If it's too bright/dark compared to the original, it's maybe because of glide gamma ramp is disabled in the default config for dgv (1.31, 1.40), but if it's unacceptable even with that enabled, you can still control the gamma correction. Have you tried that? 😐

Without knowing what I was exactly doing, I replaced the original dgvoodoo's glide2.dll with the one found in evoodoo, added also glide3.dll from the latter (this one was useless to my purpose, as I discovered recently), and wow... now the graphics are exactly the same as the original, textures are perfect, I can even read the titles. Unfortunately (obviously, you'd say...) dgvoodoo notice the change, and dgvoodoosetup menus become greyed out.

It sounds very unbelievable, if it run with dgv's glide2x.ovl then it must be dgv's glide2x.dll too!! 😀 The DOS driver of dgvoodoo (glide2x.ovl) cannot drive any of glide2x.dlls but only its own. So, mixing of components of dgvoodoo and other wrappers won't work at all.
BTW, what do you mean under 'writings are unreadable'?

By the way dgv 1.40+ and 1.50beta don't work for me.

What happens when you try to run TR1 with them?

I think "writings unreadable" means "texts unreadable"...

Sure... you're right Zup (I warned you all! My english sucks...) 😁
I meant the text (e.g. "Play, "Controls", etc.) in the main menu.
Perhaps before posting here it would have been better for me to give a closer look at the faq page, at the tombraiderchronicles site. I did some more tests today and the situation suddenly has changed. Nevertheless many doubts remain.
I finally got dgv 1.31 working. The texts are now readable and the alpha level seems right (yet, I'm not able to take screenshots), but I had to change so many settings. Now I'm not sure if it was thanks to:

1) disabling the default/basic Vesa support (it probably has to do with win 9x, not XP) - either from dgvsetup, and from the advanced link properties (the VDM Sound stuff, i'm not sure...)
OR
2) choosing DOS Platform and/or disabling VDD mode
OR
3) selecting a different DSP version for my Soundblaster card.

Troubleshooting is really difficult because dgvsetup (at least v1.3) does not remember my last settings. It seem to reset to default every time it's invoked.

As for the glide2.dll I found in the evoodoo package, I could swear that it works fine with the glide.owl - or maybe the .dll I added screwed up totally dgv, so I was running the game without any other support than VDM Sound... and the new glide2.dll
I really don't know! 😕
P.S.
I forgot to thank you, Dege, for your efforts!

EDIT: In the readme file I found something interesting about exporting dgv configuration using the command line options. I hope that soon my reports are going to be more accurate. I will test 1.40+ and 1.50 as well.

I'm a total newbie, but finally I did it... I managed to write a "config.cmd" script to export my dgvoodoosetup preferences to a file (both in .cfg and .txt format). Unfortunately v1.31 doesn't support command line parameters.
I'm using v1.50 beta now.
I can start the game, load savegames and even take screenshots (using the clipboard - though it is configured for output to file 😕 )
I'm experiencing missing textures (sort of transparency) and other minor problems. Here's some attachment: a config.txt (a shell script indeed, .cmd extension), Myconfig.txt (the output of the script) and finally a screenshot of the game.

EDIT: Version 1.40+ crashes to desktop with the same settings, but still I can ear the intro music. There's no way to stop that music from the Task manager because there are no tasks listed there, so I have to wait until it ends (or simply restart the game).
"Minor problems" of 1.50beta: the icons for "controls" and "detail levels" in the main menu appear in the foreground (they show up before the open "passport"). Again that strange transparency! Could it be something wrong in my config script? You can notice that many entries are missing, I assume that those are loaded directly from the wrapper file (glide.dll or glide2.dll).
I'm using the /NoSave switch to prevent modification of the original glide dlls.
Added a new screenshot (rar archived jpeg).
Consider that my dgv is installed locally, in the game folder.
EDIT 2: Can't find a cmdline option to force DirectX9 API.