Are u sure? the grey gaps look like there from the window

Snover wrote:

Make it work for W2K first! *cry*

Wish I could: I work mainly on W2K. It isn't a Glidos
problem, as far as I can tell. My copy seems to have
trouble reading its own files under W2K: if I had .dem
files present then it fails while reading their headers.
Otherwise I get background and no menus, probably because
it fails to read the menu texdt from the config file (or is it the ini file?).

Glidos wrote:

Wish I could: I work mainly on W2K. It isn't a Glidos problem, as far as I can tell. My copy seems to have trouble reading its […]
Show full quote

Wish I could: I work mainly on W2K. It isn't a Glidos
problem, as far as I can tell. My copy seems to have
trouble reading its own files under W2K: if I had .dem
files present then it fails while reading their headers.
Otherwise I get background and no menus, probably because
it fails to read the menu texdt from the config file (or is it the ini file?).

Did u know that u can record ur own demos

type spielberg <episode> space <map> then it will record a demo, when ur dead or, finished the level, press spacebar, quit blood, and rename it blood0000.dem (or any number u want)

heh, wow, Unregistered, that is the most counter-productive thing to mention when we're trying to get it to work. It doesn't mean anything as far as getting the Blood working. Thanks, though.

I noticed that same problem, except that the 3DFX.EXE that DosFreak posted didn't even try loading the demos (hence I got a black screen with menu that WORKED). INT13h again?

Oh, and yes, I'm positive it has nothing to do with running it in full-screen versus windowed mode -- the grey boxes occur in both modes, and there aren't ANY windows open when I run the game.

Whats the difference if blood 3dfx runs with long thin tryangles then ordinary squares?

Well I just tried this update and blood still works. yay! 😀

Unregistered wrote:

Whats the difference if blood 3dfx runs with long thin tryangles then ordinary squares?

The triangles don't space fill. They leave gaps unless you match resolutions, in which case the triangles come out as one pixel wide lines (the same as rectangles would). With the change to rectangles, you can set Glidos's resolution to 1280x1024 if you like and you still don't get any gaps in the rendering because the rectangles all abut onto each other.

Also Blood was leaving the texture coordinates on one of the triangle apexes floating. I've also made Glidos put that right. The floating texture coordinates matter on some OSes with some graphics cards, but not others. Most of the graphics anomalies were caused by this.

But that still doesn't get it running in Win2K! *sob*

Have any hunches, Paul? Fabio?

You said something about int 13h. What does that do?... yeh I could look it up but I'm lazy. I've made Glidos intercepy problematic DOS ints in the past. Maybe this one needs some fixing.

INT13h is the happy thing that's not implemented in Windows 2000 but is in XP that decides whether or not BUILD and DOOM engine games will lock up or not. 😀 Read about it in the VDMSound forum (also see CLI2NOP). It's ALL the rage in...uh...Microsoftland! 😜

How come my 3dfx blood is really slow on ny comp with winxp and a nvidia geforce2 grapics? (I've realised my blood gets slower later in the game)

Unregistered wrote:

How come my 3dfx blood is really slow on ny comp with winxp and a nvidia geforce2 grapics? (I've realised my blood gets slower later in the game)

GF2 MX?
What processor speed?
Are you using Windows XP and if so are you using the installed Microsoft drivers or Nvidia drivers? Not sure if MS Emulated OGL works with OpenGlide but it is a possibility.

I'm useing the nvidia drivers for my gf2 Ti graphics card, but my processor is a crappy 400mhz celeron

>>but my processor is a crappy 400mhz celeron

Well then, there you go.
Geesh

It's like having a car that looks identical to a Porche 911, it has all the trimmings, spoiler, body kit, etc.. And wondering why it's soooooo slow because it has a 1 litre engine inside it.

Yeh, Glidos has a heavy job to do piping Graphics commands from DOS to Windows. A 400MHz processor just hasn't got it. Memory speed matters also. Once the commands get to your graphics card, though, you've got miles of power to spare in a GF2.

Snover wrote:

INT13h is the happy thing that's not implemented in Windows 2000 but is in XP that decides whether or not BUILD and DOOM engine games will lock up or not. 😀 Read about it in the VDMSound forum (also see CLI2NOP). It's ALL the rage in...uh...Microsoftland! 😜

How sure are you that it is an int 13h problem? I've just looked at int 13h on the ralph brown site and its all about direct access to discs. A few things confuse me.

1) Why would a game use direct access to the disc, except for some sort of copy protection?

2) Redguard does direct disc access and W2K puts up a warning box. If Blood is doing the same, why don't we get a warning box.

Got any good links to explanations of the int 13h problem?

Glidos wrote:

Yeh, Glidos has a heavy job to do piping Graphics commands from DOS to Windows. A 400MHz processor just hasn't got it. Memory speed matters also. Once the commands get to your graphics card, though, you've got miles of power to spare in a GF2.

Why not make glidos rely almost entirely on the GPU rather then the CPU? (if they don't have a GPU such as a TNT2 or rage pro graphics, make glidos go back to the CPU)

Unregistered wrote:

Why not make glidos rely almost entirely on the GPU rather then the CPU? (if they don't have a GPU such as a TNT2 or rage pro graphics, make glidos go back to the CPU)

The problem is piping information from a DOS program to the Windows environment. Your GPU can't help you with that problem.

I'm *pretty* sure it's INT13h... like I said, search for CLI2NOP. Good info there.

Maybe it's not INT13h... I dunno... I could've sworn that's what it was, though. Implemented in XP, but not in 2000.

Glidos wrote:

How sure are you that it is an int 13h problem? I've just looked at int 13h on the ralph brown site and its all about direct access to discs. A few things confuse me.

Let's ignore INT13H for now. Could it be a CLI-related issue, though?
showthread.php?threadid=31

I'm not sure where Colin is getting this INT13H thing. First time I've seen it mentioned at VOGONS. Unless he's trying to refer to the VDMControl undocumented call for Build-based games (and others that required CLI2NOP) under WinXP that gets around the PUSHF/CLI/POPF problem. But that's not INT13...

I'd like a better explanation from Colin, too. 😀