I tried a few of those to no avail. Then again I am as dumb as a box of rocks when it comes to this.

Hello

@dege:

Flint: Hmm. I dont want to bring bad news but in TR1 there are not all textures with DGV 1.40bR2.

Dege: Hmm, does only 1.40Br2 do it, or r1 too?

Only 1.40Br2 does. 😐

Flint: I can disable the D3D-Clipping but I have to restart the computer. Then all graphics in GTA(full-version) are fine.

Dege: It sounds very strange to me! Why do you have to restart the computer?

I don't know. After starting DGV once with d3d-clipping and disabling it after playing GTA I can't start GTA again because it doesn't find a 3dfx-chip.

But I found out that the acer-graphic-driver for my laptop is too old. ATI doesn't give drivers for mobility chips so I have to wait till Acer produces a newer one. 😢 🙁 😠
I'm going to try the Omega-ATI-Catalyst 5.7 drivers, some people say they work on mobility chips. Maybe this solves the problems. 😖

@crisis123:

Flint - For Archimedean Dynasty: Did you try just one level or all? For me AD does work with a few missions, but other just crash on start (those are always the same, btw!).

You are right. Only some missions are playable.

I'm using WinXP, wit nolfb and vdmsound with an ATI Radeon 7500

Hmm. I never got ingame on winxp and I'm also using nolfb and vdmsound. The shot is made on win98 on the 2. PC. So how did you do this on WinXP? 😕 I think I should really try the Omega drivers on my Laptop. 😦

Hmm. I never got ingame on winxp and I'm also using nolfb and vdmsound. The shot is made on win98 on the 2. PC. So how did you do this on WinXP? Confused I think I should really try the Omega drivers on my Laptop.

Well, I just use vdmsound launchpad, basic vesa-emulation enabled. (the dgvoodoo vesa disabled!) in the advanced options I put into the "autoexec.bat"-field the path to nolfb. that's all. I don't think, I did anything else, afaik.

Here is my vdmsound-launchpad-config - the .vlp file (note: of course, you have to adjust your paths for your system), so you can try to use it as a base and hope it works for you 😀

1[program]
2workdir=C:\SF
3params=
4executable=C:\SF\sf3dfx.exe
5[winnt.memory]
6useEMS=no
7[winnt.video]
8useVESA=yes
9[vdms.midi]
10sysExLed=Scroll
11enabled=no
12[winnt.dos]
13autoexec=c:\sf\nolfb.com
14config=FILES=80
15[winnt.scheduling]
16detectIdle=yes
17idlePrio=50
18compatHWEmu=yes
19[winnt.dosbox]
20exitClose=yes
21[vdms.gameport]
22mapFile=E:\VDMSound\joy2.map
23[vdms.sb.dsp]
24version=3.02 (SoundBlaster Pro 2)

Have problem vgdoo 4.0

see here picture.
http://members.home.nl/twog86/CarmageddonSplatPackCrash.jpg

To eagle car work good see dashboard.
And will another car not eagle car, not can see dashboard crash.

Iàm not good english.
i hope yes you good my english begrip.

and thanks

greets twog86

Thanks for your feedback!

EDIT:

Indeed, seems to be a bug again, tomorrow I will have a look at there. 😎 😐

Well, it's not. It is the same problem I wrote about earlier:

- Camera overlay on the top left is not completely visible when using cockpit view.

Yes, I remember. Carmageddon locks the color buffer in a very arrogant way. It not only swaps the buffers between lock-unlock but even draws primitives by the hardware into that locked buffer. That was nice to handle. Carm keeps the buffer locked while it renders into it, and dgVoodoo flushes the direct lfb writes only when the buffer gets unlocked. So it locks the lfb, draws the environment (buildings, etc), then draws the cockpit with direct writes, then it draws the "portrait" of the driver by 3d hardware again. So, this portrait is behind the cockpit because the cockpit gets flushed out to the screen last. The real solution in a such situation would be to flush out the direct lfb writes every time the application draws a primitive (but how would we know whether there is or there isn't something to flush. If we flushed at every triangle, that would be very time consuming). I tried it, the appearance was correct, but the game obviously slowed down. I'm afraid this is a glitch that can never be fixed.

So, seeing only a black/white filled cockpit is because of exactly the same problem: wrong order of flushing LFB-writes and drawn primitives. dgVoodoo would need more sophisticated methods to be able to handle correctly such (a f...ing) type of LFB lockings like in Carma. 😒
It may come off one day in a new version... 😈

Don't know how dgVoodoo implements LFB access. Glidos works only in server mode, and doesn't do anything clever about interprocess memory access, so it has to do LFB writes by blue screening (lock fills the buffer with blue, and unlock flushes the buffer with blue taken as transparent). When you work that way, you can check each drawn primitive to see if it overlaps anything that has gotten written to the LFB, and flush the whole thing (refilling with blue of course), if it has. You wouldn't have to be that accurate; you could expand each triangle to its containing rectangle and check that for overlap (there's not harm in performing the odd unnecessary flush).

Not that I've implemented this. Never gotten around to it.

Blue screening isn't ideal anyway. Took me ages to figure out why the blue keys never appeared in D2 😁

I got Incubation running with dgVoodoo by replacing some entries in eng3dfx.dll, game works but there is a crash when you exit the game.
Anywhy these functions eng3dfx.dll is looking for in glide2x.dll (which are missing from dgVoodoo's glide2x.dll):

_grSstConfigPipeline@12
_grSstVidMode@8
_guMPDrawTriangle@12
_guMPInit@0
_guMPTexCombineFunction@4
_guMPTexSource@8
_guMovieSetName@4
_pciFindMTRRMatch@16

Putting these functions in dgVoodoo should make Incubation work without any hacking.

Wow! I just tried dgVoodoo 1.4. Fantastic work! The performace is incredible! Using 1.31 I set the Yon (draw distance) value in carmageddon's options to 100.0 and got about 30fps in most areas (Running at 1600x1200 mind you.). With 1.4 the framerate isn't going below 70! Also, great work on fixing the fog.

Edit: Hmm, one small problem... your cars movements aren't smoth somehow. They're kinda bumpy. This is especially noticable when travelling up a steep hill. I don't know how dgvoodoo would affect it like that but it does. I'm sure this never happened with 1.31. I'm going to test it with both. Maybe i just never noticed it.

Edit2: I was right, this doesn't seem to happen with 1.31.

dgVoodoo does bluescreening too, if "fastwrite" is enabled (yes, I call it "fastwrite" 😀) otherwise it reads back all the color buffer content to prepare writing (it's "slowwrite", not too effective, so it can be considered obsolete, except for one case, when dgV can give back the pointer to the ddbuffer directly).
Paul, bounding box technique would help of course, but I'm not sure if it's enough to keep the performance at an acceptable level, I want to avoid needless flushing completely. Formerly I was thinking on using inaccessible pages/exceptions trick, but Win32's Structured Exception Handling is useless in this aspect. AFAIK, vectorial exception handling has (re)appeared first with XP (as it was done under DPMI and win16, good old days, hehe), but number of problems grows with making Dos and win exception handling cooperative, especially in an interprocess environment.

Blue screening isn't ideal anyway. Took me ages to figure out why the blue keys never appeared in D2

hmm, what do yo mean by "D2"? 😀

@Miki Maus: Ah, thanks, most of them should have been in the dll, but they were commented out in the src for some reasons. Fixed!

@TomB: Yes, gameplay isn't so smooth with 1.40 because of timer boosting of dgV. 1.31 did it with 15 ms period time, while 1.40 does it with 40 ms. I tried 1.40 with 15 ms, the game is faster, but seems to be smooth. You can't modify this value in v1.40, but will be able to do it with 1.40+. 😀

I think Carma (as most other games) synchronize itself to the 60Hz(?) refresh freq using the timer. It's bizarre that it need to be finetuned to make it almost perfect. (or, the problems is in dgV itself, or in NTVDM's timer emulation, don't know, should see what happens under w98 😀 😎 )

Dege wrote:

dgVoodoo does bluescreening too, if "fastwrite" is enabled (yes, I call it "fastwrite" 😀) otherwise it reads back all the color buffer content to prepare writing (it's "slowwrite", not too effective, so it can be considered obsolete, except for one case, when dgV can give back the pointer to the ddbuffer directly).

Yeah, I've been experimenting with DirectX and direct access to buffers lately. That's so nice, and dithered 16bit really doesn't seem to look any different from 32bit.

Paul, bounding box technique would help of course, but I'm not sure if it's enough to keep the performance at an acceptable level, I want to avoid needless flushing completely.

I have this suspicion that Carmageddon writes to the lfb just once per frame, so there might only be the one flush. But still the testing for every
triangle may be too much work.

Formerly I was thinking on using inaccessible pages/exceptions trick, but Win32's Structured Exception Handling is useless in this aspect. AFAIK, vectorial exception handling has (re)appeared first with XP (as it was done under DPMI and win16, good old days, hehe), but number of problems grows with making Dos and win exception handling cooperative, especially in an interprocess environment.

Yeah, I wondered about that approach, but it frightens the hell out of me 😁 My DOS knowledge amounts to what I've learnt in the process of writing Glidos, so I'd lose a month of my life getting something like that working.

Blue screening isn't ideal anyway. Took me ages to figure out why the blue keys never appeared in D2

hmm, what do yo mean by "D2"? 😀

Descent II. I actualy used blue for blue screening at first. And D II was trying to write blue to lfb.

Yeah, I've been experimenting with DirectX and direct access to buffers lately. That's so nice, and dithered 16bit really doesn't seem to look any different from 32bit.

Yes, indeed it's nice, but can only be used rarely, when the lock origin is upper left, no scaling, write format is the same as ddbuffer format, glide app doesn't expect 2048 byte stride as on a voodoo1, no buffer swapping between unlock/lock, etc. 😀
But, it's still a nice case for most of the applications when the wrapper is not encumbered with non-default settings like 32 bit mode and so on. 😀

Yeah, I wondered about that approach, but it frightens the hell out of me My DOS knowledge amounts to what I've learnt in the process of writing Glidos, so I'd lose a month of my life getting something like that working.

Well, maybe it wouldn't be so frightening, just a function should be called from exception handler of DOS to make the wrapper aware of the modified/read page (could be implemented as calling of any other glide-function). Bad things are analyzing the instruction that caused the exception whether it's because of accessing our pages or not, and can't get around keeping the exception handler first in the chain. Worse in Win32. 😐

Descent II. I actualy used blue for blue screening at first. And D II was trying to write blue to lfb.

Ah, yeah, it's in on the deal, that's why I kept non-bluescreening. At least one can try it if bluescreening is the bad and use non-bluescring. The game probably will be very slow, but, still there is a way to change the colorkey to other value. 😀

Dege wrote:

Yeah, I've been experimenting with DirectX and direct access to buffers lately. That's so nice, and dithered 16bit really doesn't seem to look any different from 32bit.

Yes, indeed it's nice, but can only be used rarely, when the lock origin is upper left, no scaling, write format is the same as ddbuffer format, glide app doesn't expect 2048 byte stride as on a voodoo1, no buffer swapping between unlock/lock, etc. 😀
But, it's still a nice case for most of the applications when the wrapper is not encumbered with non-default settings like 32 bit mode and so on. 😀

With the origin being lower left, I wondered about returning a pointer to the bottom line and a -ve lineskip. Naughty, but might work for a lot of games.

With D3D9 it looks like you can't get sensible access to the front buffer, so probably forced to keep the two glide buffers separate from the swap chain - render to the glide buffers, blit them to the D3D backbuffer and present. Inefficient but I can't see another way.

Anyway, with that way of working the origin being lower left could be dealt with by rendering everything upsidedown, and rectifying it on the blit... maybe.

With the origin being lower left, I wondered about returning a pointer to the bottom line and a -ve lineskip. Naughty, but might work for a lot of games.

Yes, it would probably work, but indeed it's naughty since the type of lineskip is unsigned int.

With D3D9 it looks like you can't get sensible access to the front buffer, so probably forced to keep the two glide buffers separate from the swap chain - render to the glide buffers, blit them to the D3D backbuffer and present. Inefficient but I can't see another way.

Exactly, StretchRect is supposed to work between two surfaces with rendertarget type.
But, I'm missing that rich api in dx9 that was present in ddraw7. StretchRect seems to be the only way to blit between hw buffers (with strong restrictions tough), but there is no colorkeyed/mirrored blits like in ddraw7.
I think dx7 is the most efficient interface for such emulation purposes but it has the drawback of lack of pixel shaders and other technologies. It seems to me that MS went on a way to make new DX interfaces be more OpenGL-like, and I don't like it at all. I can't beleive in their blablas saying that removing ddraw was a good step as mixed 2D/3D causes permormance loss, etc.
They should just have removed the still-unsupported working modes from dd like blitting with rotating or alpha blending,.., and left the other basic things like blitting with strecthing/mirroring/cking. OK, they should do write in the docs about the perf loss when switching between the 2d blitter and 3d hw, but, every developer should be able to decide whether he/she take it in or not. 😐

You looking at Dx9 too. Maybe we should pool resources. I'm getting close to releasing a first version of psVoodoo. Was thinking of making it open source. It seems a bit slow, but then its only a few weeks old. I was intending to use pixel shaders for everything, but was frightened off learning too much in one go, so Color/Alpha combine is all done with stage state stuff at the moment.

I AM now using pixel shaders to handle the lack of paletted texture support. Runs RedBaron really smoothly on my X800, but then again, so does dgVoodoo - how do you do that? You must be doing something clever there.

psVoodoo? 😎 You're working on a D3D9-based wrapper? It makes me very curious! 😀
(Damn, I was planning putting a D3D9-renderer into dgVoodoo, too, to make use of best of both world, dx 7 and 9 😁 )

You looking at Dx9 too. Maybe we should pool resources. I'm getting close to

Yes, we could discuss about directx issues/etc. 😀

I AM now using pixel shaders to handle the lack of paletted texture support. Runs RedBaron really smoothly on my X800, but then again, so does dgVoodoo - how do you do that? You must be doing something clever there.

How did you get around the bilinear-filtering problem in pixel shaders? It sound interesting...
dgV doesn't do any trick, yet. It simply reloads all texture data when a palette changes.

Dege wrote:

psVoodoo? 😎 You're working on a D3D9-based wrapper? It makes me very curious! 😀
(Damn, I was planning putting a D3D9-renderer into dgVoodoo, too, to make use of best of both world, dx 7 and 9 😁 )

No reason why you shouldn't. I'm also interested in having multiple rendering paths. I don't think it would be unreasonable to have a bottom layer that calls between either DX or OpenGL. Needs more thought though

You looking at Dx9 too. Maybe we should pool resources. I'm getting close to

Yes, we could discuss about directx issues/etc. 😀

Would be a help to me, because I am new to it. I'll probably put my CVS repository up on sourceforge. Be good if you could look over it. Anything useful you could use. Anything stupid you could maybe comment on. 😁

I AM now using pixel shaders to handle the lack of paletted texture support. Runs RedBaron really smoothly on my X800, but then again, so does dgVoodoo - how do you do that? You must be doing something clever there.

How did you get around the bilinear-filtering problem in pixel shaders? It sound interesting...

Don't actually use it at scene render time, which is where the filtering problem comes in. I use it for fast regeneration on palette change. In addition to a varying 32bit version of the texture, I have an L8 (or A8L8) version on the device, plus the palette as a long thin texture. On palette change I render to the 32bit texture. The advantage being that at most you need to download the palette.

dgV doesn't do any trick, yet. It simply reloads all texture data when a palette changes.

Hmmm, strange. Before I used the pixel shader trick, psVoodoo ran RedBaron very slowly. The trick makes it pretty smooth (although that's on an X800 and a mobo with 939 memory architexture). Strange thing is that dgVoodoo is perhaps smoother still, without any tricks. This is one of the things that makes me think my lack of dx knowledge is a problem. I'm probably doing something really inefficiently somewhere.

Its so strange, I wondered whether X800s had some minimal paletted texture support which they export only under dx7, but I think that's grasping at straws.

hmmm... Mechwarrrior Titanium triolgy is DX5... is there such a thing as a DX9 to DX5 wrapper?

Carrera, If you wish to play Mechwarrior (Windows ver) under Windows then currently the only way is to use Microsoft Virtual PC.

The DOS version is superior in almost every way except mabye the enhanced D3D graphics included in the patch. The DOS version can be played in Windows XP NTVDM or in DosBox.

Would be a help to me, because I am new to it. I'll probably put my CVS repository up on sourceforge. Be good if you could look over it. Anything useful you could use. Anything stupid you could maybe comment on.

OK, I'm looking forward to it! 😎 But, I'm not expert in dx9, haven't learnt too much of it yet. 😀

Don't actually use it at scene render time, which is where the filtering problem comes in. I use it for fast regeneration on palette change. In addition to a varying 32bit version of the texture, I have an L8 (or A8L8) version on the device, plus the palette as a long thin texture. On palette change I render to the 32bit texture. The advantage being that at most you need to download the palette.

Ah, yes, regenerating the texture by hw, it's clever. 😎 There's another method to do it, without pixelshaders: bump mapping. It may sounds weird, but it can be done: using the palette indices as delta u values in the thin palettetexture. Only one extra stage is needed in the pixel pipeline, the bump mapping stage which perturbs the texture coordinates of the next stage. Haven't done any developing on this in practice though, because sw regenerating proved to be fast enough in most cases. But only in most cases. 😀

Hmmm, strange. Before I used the pixel shader trick, psVoodoo ran RedBaron very slowly. The trick makes it pretty smooth (although that's on an X800 and a mobo with 939 memory architexture). Strange thing is that dgVoodoo is perhaps smoother still, without any tricks. This is one of the things that makes me think my lack of dx knowledge is a problem. I'm probably doing something really inefficiently somewhere.

Of course, there are some optimizations like regenerating texture only in the "last minute", when it's really has to be regenerated (caching the palette changes), and checking if the texture uses the changed palette entries, etc. But the most important is to use high performance converting code in a direct 3dfx data->dx texture surface conversion. I'm using self-modifying 😊 mmx code, as I unified and rewrote all format converters in 1.40 to be able to convert from any format->any format.

Its so strange, I wondered whether X800s had some minimal paletted texture support which they export only under dx7, but I think that's grasping at straws.

No, if a device supports paletted tex format, then it's in the texture formats enumeration. But ATI and nVidia 6 and 7 series dont support it.

hmmm... Mechwarrrior Titanium triolgy is DX5... is there such a thing as a DX9 to DX5 wrapper?

You mean DX5 to DX9 wrapper? 😀 I dont know of any. DX->DX wrapping would be pretty complicated, because DX exposes its interfaces as COM interfaces.

Not to go offtopic again but I don't believe the problem with Mechwarrior2\Mercs is a DX problem....at least not directly. You can setup 9x on your host with DX9, install Mechwarrior 2 and it'll work just fine. No matter what DX you use on 2000/XP (DX7-9) it won't work after the CD check.

So it's some diff between DX 9x and DX NT or one of the other system files....mabye Miles or something....