Unregistered wrote:

Try running blood with glidos vesa support its just as slow on wXP as on w98 so it doesnt have much difference,
If that doesnt work well atleast I suggested something

I tried that. It just gives up without an error message. What version of Blood are you using? Any tricks in the install?

I'm useing the same version as u.
u have to run at 640x480 resolution only i think

Unregistered wrote:

I'm useing the same version as u.
u have to run at 640x480 resolution only i think

Set what to 640x480? Setting Glidos to 640x480, can't really make any difference. I tried editing the CFG file, and that didn't help. Any other ideas?

I deleted the demo files, and now I get as far as getting the messages appear in the Glidos server window, and having Glidos open a game window. The game is reporting 512x384 resolution.

Someone reported actually having it running, but slowly. How do I get to that stage? Could that person put their nearly working copy somewhere safe, and reinstall seeing if they can recreate any tricks they used. Avoid doing anything like testing the installation on a real Voodoo card, because that could potentially
trigger some initialisation that I wont be able to recreate here.

Glidos wrote:

I'm using Blood one whole unit with 1.3MB patch.

If you're using "Blood one whole unit" (v1.21), it should not work with the 3dfx patch. Despite what "unregistered" said, I tried this back when I had an original voodoo card and I was using Win98. Tried in DOS and in Windows and got nothing. If somebody else got it work with theirs, you can safely bet that it's a lucky fluke.

both glidos and blood need to be 640x480 rsolution,
If blood one whole unit cant run 3dfx then how come i got it to work on old my voodoo banshee
(note: i made a 3dfx.bat file to get it to work on it, but it made no difference for glidos)

Unregistered wrote:

If blood one whole unit cant run 3dfx then how come i got it to work on old my voodoo banshee

Like I said, lucky fluke. When the patch was made the Banshee didn't even exist. I also tried this with a Voodoo Rush and got the same results.

I think its win98 im getting blood one whole unit running but its distorted, hers what glidos controle said:

Starting Glide Server v1.19 (c) Paul Gardiner 2001-2002
Resolution = 512x384
Refresh rate = 60Hz
Color format = ABGR
Number of color buffers = 2
Number of aux buffers = 0
GRTEXCOMBINE@28
WinClose
Resolution = 512x384
Refresh rate = 60Hz
Color format = ABGR
Number of color buffers = 2
Number of aux buffers = 0
GRTEXCOMBINE@28
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
GRTEXCALCMEMREQUIRED@16
WinClose
GlideShutdown
I cant get it to 640x480 its probably glidos but at least i dont get a blank screen like others

Glidos,
Do u think u can make ur program read 3df format files thats what blood 3dfx uses.
I think this is what XGL200 glide wrapper has done:

XGLLINK uint32 XGLCALL gu3dfGetInfo(char *filename, XGL3dfInfo *info) {
vlog("Called gu3dfGetInfo: filename=" << filename);

ifstream f;
int i, smalllod=1, largelod=1, w_aspect=1, h_aspect=1;
char s[256], fmt[8];

f.open(filename);
if(!f.is_open()) {
log(" Could not open " << filename << " in gu3dfGetInfo");
return XGLFALSE;
}

for (i=0; i<11; i++) {
f >> s;
switch (i) {
case 2: strcpy(fmt, s); break;
case 5: smalllod = atoi(s); break;
case 6: largelod = atoi(s); break;
case 9: w_aspect = atoi(s); break;
case 10: h_aspect = atoi(s); break;
}
}
f.close();

int slod, llod;

switch (largelod) {
case 256: llod = XGLLOD_256; break;
case 128: llod = XGLLOD_128; break;
case 64: llod = XGLLOD_64; break;
case 32: llod = XGLLOD_32; break;
case 16: llod = XGLLOD_16; break;
case 8: llod = XGLLOD_8; break;
case 4: llod = XGLLOD_4; break;
case 2: llod = XGLLOD_2; break;
case 1: llod = XGLLOD_1; break;
default: llod = XGLLOD_1;
}

switch (smalllod) {
case 256: slod = XGLLOD_256; break;
case 128: slod = XGLLOD_128; break;
case 64: slod = XGLLOD_64; break;
case 32: slod = XGLLOD_32; break;
case 16: slod = XGLLOD_16; break;
case 8: slod = XGLLOD_8; break;
case 4: slod = XGLLOD_4; break;
case 2: slod = XGLLOD_2; break;
case 1: slod = XGLLOD_1; break;
default: slod = XGLLOD_1;
}

int width = largelod, height = largelod;

info->aspect = getAspectRatio(w_aspect, h_aspect);
switch (info->aspect) {
case XGLASPECT_8x1: height >>= 3; break;
case XGLASPECT_4x1: height >>= 2; break;
case XGLASPECT_2x1: height >>= 1; break;
case XGLASPECT_1x1: break;
case XGLASPECT_1x2: width >>= 1; break;
case XGLASPECT_1x4: width >>= 2; break;
case XGLASPECT_1x8: width >>= 3; break;
}

info->width = width;
info->height = height;
info->smalllod = slod;
info->largelod = llod;
info->format = getTextureFormat(fmt);

// info->palette

info->data = 0;

info->mem = getMemRequired(info, smalllod, largelod, w_aspect, h_aspect);

vlog(" smalllod=" << smalllod);
vlog(" largelod=" << largelod);
vlog(" w_aspect=" << w_aspect);
vlog(" h_aspect=" << h_aspect);
vlog(" width=" << info->width);
vlog(" height=" << info->height);
vlog(" mem=" << info->mem);

return XGLTRUE;
}

XGLLINK uint32 XGLCALL gu3dfLoad(char *filename, XGL3dfInfo *info) {
vlog("Called gu3dfLoad");
ifstream f;
char s[51];

f.open(filename, ios::binary);
if(!f.is_open()) {
log(" Could not open " << filename << " in gu3dfLoad");
return XGLFALSE;
}

f >> s;

f.read(info->data, info->mem);

f.close();

return XGLTRUE;
}

uint32 getMemRequired(XGL3dfInfo *info, uint32 smalllod, uint32 largelod, uint32 xaspect, uint32 yaspect) {
uint32 pixels = 0;
uint32 i;

log(smalllod << " - " << largelod << " - " << xaspect << " - " << yaspect);

for (i=smalllod; i<=largelod; i *= 2)
pixels += i * i / (xaspect * yaspect);

return (pixels * getBytesPerPixel(info->format));
}

not sure if it would be any help though since i dont know what programming language it was made with, might be C++

I've fouind out how to make blood work in 640x480. and to get it not to bother with the .3df files. I've also added the grTexCalcMemRequired call. Now it limps along to some extent, although only uder W98

I'll try to release some files here later for you to play with.

Looks like Blood isn't going to be a goer in the long run. The 3dfx port was done by converting the build engines scan line plots into long thin triangles, with a palette change for each scan line to give lighting effects. This is going to create a high data flow between DOS and windows, and its also going to look crap.

so u got blood 3dfx textures looking right, I thought without the 3df files it doesnt go to 3dfx format.

Also can u send me a test version of the glidos u made, I'll like to try it out on my computer.

My email:

infuscomus@hotmail.com

Unregistered wrote:

so u got blood 3dfx textures looking right, I thought without the 3df files it doesnt go to 3dfx format.

No they don't look right, but I think that's because Glidos doesn't know how to handle ABGR.

The 3df files are just a cache on hard disc, so that the translation can be done just once. Turning off the cacheing shouldn't make any difference to the look of it, unless because of a bug (which is of course possible).

Also can u send me a test version of the glidos u made, I'll like to try it out on my computer. My email: infuscomus@hotmail. […]
Show full quote

Also can u send me a test version of the glidos u made, I'll like to try it out on my computer.

My email:

infuscomus@hotmail.com

I'll post some files here, but later: I'm working now.

I know this isn't Blood, but this is from the readme in Shadow Warrior 3dfx. This had a proper release and not an alpha, like in Blood.

I'm posting this because they both use the build engine, and they both do exactly the same things when trying to use Glidos.

Readme.

3Dfx Shadow Warrior does not support 3D sprites like regular
Shadow Warrior does. This was a technical impossibility. For this
reason, the 3D sprites option has been removed from the options
menu. Be sure to turn 3D sprites off in regular Shadow Warrior
before running the 3Dfx version for the first time. If you do not
do this, then no sprites will appear in the 3Dfx version.

Q: Why does my status bar look garbled?
A: Some of the larger textures (like the status bar) are converted
to 3Dfx format the first time you run 3Dfx Shadow Warrior.
Sometimes these textures can become corrupted. Try deleting the
TX3DFX subdirectory in your Shadow Warrior directory and
running 3Dfx Shadow Warrior again. It will reconvert the
textures again.

Also Shadow Warrior has to do a lot of extra work to get onto the
3Dfx that a "real" 3D game does not. We end up having to deal with
many more polygons per frame than a game like Quake, Jedi Knight or
Hexen II. This is detailed more in Scott Alden's 3Dfx notes below.
Notes from 3Dfx and environment variables
-----------------------------------------

3Dfx Build Engine Version 1.0
Author: Scott Alden
Date Created: 9/12/1997
Last Update: 11/22/1997

3Dfx Build Engine Version 1.1 update
Author: Jack Mathews / 3Dfx

Implementation Notes
--------------------
I had a lot of fun and challenges on working on the
Build engine, not everything went as I wanted it
and many things are workarounds. Sloped floors
were especially fun 😉 An ideal thing to happen is this
engine is converted to true polygon rendering system.
This could greatly enhance the speed for the 3Dfx hardware.

I currently have the raster layer of the build engine
rendering spans to the 3Dfx hardware. Thus a wall that
fills the entire screen would be made up of X triangles
where X = the horizontal resolution of the screen.
You can set the BUILD_TRICOUNT (see below) environment
variable to see how many triangles are being drawn on
the previous frame. This is more for seeing how the
tricount affects the framerate. Since each wall and
floor is made up of hundreds of spans, thus thousands
of triangles are drawn each frame. For instance if
a single wall was rendered in a frame that filled the
screen, the renderer would have to draw 640 vertical
triangles to draw the wall.

All of the tiles in the game are downloaded to the
hardware as texture maps, and the span is converted
to the 3Dfx format for rendering. There are 3 types
of primitives that I use: horizontal triangles for
horizontal spans, vertical triangles for vertical spans,
and quads for drawing unclipped sprites.

Also, the lighting/palette effects that the game
uses are achieved by downloading a new palette to the
3Dfx hardware. This palette downloading happens on
a span by span basis. Fog and other lighting effects
are all achieved by palette changing.

A span based renderer is slower than the an ordinary
3D based renderer (like GLQuake) on the 3Dfx because
of the conversion of spans involved. For each vertical
span in a wall, the texture coords must be calculated
specifically for the span, where as a regular polygon
for a wall only has to provide texture coordinates at
the vertices.

-----------------------------------------------------------

Here are some extra things to know about for
additions I have made to the build engine which
can be set in your environment before running
the game:

Environment Variables
---------------------
The BUILD_640X480 environment variable is used
to run the game in the 640x480 resolution.
The default setting is 0, and the default resolution
is 512x384.
e.g. set BUILD_640x480=1

The BUILD_RESAMPLE environment variable is used
to control how the game and animation textures
are converted to 3Dfx format. If you set this
variable, the slower method of sampling and blending
is used. This gives a more desirable image however
it takes a long time to run, and it gives a dark
halo effect surrounding sprites (i.e. the fists
and some menu bar things). The faster way uses
point sampling, it provides a more grainy conversion,
but is a lot faster than the previous method.
You only need to convert the textures the first time
you run the program, and if you want to recreate
them, delete the "tx3dfx" and animxxxx directories
which contain all the .3df files.

The BUILD_BRIGHTNESS environment variable is used to
brighten the colors of the textures that are used in
the game engine. The colors will be brightened by this
factor, and will saturate to white. The default setting
is 2.5.
e.g. set BUILD_BRIGHTNESS=2.8

The BUILD_NOPAL environment variable is used to turn
on palette downloading on a per-span basis.
!!!Warning!!! This will affect the color palette of the game
and the colors may not be correct! This is only provided
as a speed boost. The default setting is 0.
e.g. set BUILD_NOPAL=1

The BUILD_NOFOG environment variable allows the game
fog to be turned on/off. This is provided as a
speed boost. The default setting is 0.
e.g. set BUILD_NOFOG=1

The BUILD_CONVTEXTURES environment variable is used
to control whether or not textures are cached to disk.
If BUILD_CONVTEXTURES is set to 1, then the textures
will not be cached to disk and will be converted in
memory. If you are running the game under Windows 95,
then this setting is not recommended. If you are
running the game under DOS, then this setting may help
out because disk I/O access is slower on some
DOS machines than others. The default setting is 0.
e.g. set BUILD_CONVTEXTURES=1

The BUILD_TRICOUNT environment variable shows the number
of triangles drawn in the last frame. The default setting
is 0.
e.g. set BUILD_TRICOUNT=1

The BUILD_FPS environment variable shows the current clock
settings, frame number, and a (rough)FPS count.
The default setting is 0.
e.g. set BUILD_FPS=1

The BUILD_VERSION environment variable shows the current
version number of the 3Dfx Version of the Build Engine
and the current version of Glide you are using below that.
The default setting is 0.
e.g set BUILD_VERSION=1

BUILD_MRED, BUILD_MGREEN, BUILD_MBLUE set the colors
of mirrors in the game respectively. Their range is
from 0-255. Their default settings are 200, 200, and 255
respectively (gives a blue tinge to all mirrors)
e.g. for dark blue mirrors:
set BUILD_MRED=0
set BUILD_MGREEN=0
set BUILD_MBLUE=200

------------------------------------------------------------
Here's some things I added to the Shadow Warrior code
and specific things in the build engine that are
related to Shadow Warrior.

When you start up Shadow Warrior 3Dfx version, the
program will begin converting the textures in the game
to the 3Dfx format. This only needs to be done once, and
if you want to recreate the process, then delete the
subdirectories called tx3dfx and animxxxx where xxxx will
be a number and the directory will contain .3df files.
This takes quite a while to convert so be patient 😀
See the above environment variable BUILD_RESAMPLE for
more information on this.

Some if these explanations from the programmer 'may' help in getting them to work with glidos.
Don't know if any of that helps, Paul ?
But you'll have Shadow Warrior soon, anyway 😉

One point to note is this,
When you first run Blood in 3dfx mode, all the textures are meant to be converted to 3dfx mode, and placed in the TX3DFX directory.
But under Glidos they aren't, and perhaps thats why it doesn't run ?
Perhaps someone could install Blood, patch it, and run it on a real Voodoo card to see what happens. Then, if the textures are converted and it runs, try running it under glidos.

😀 Great posting that! It should be useful to Paul (but I still think it'll look like crap. 😀 )

I'd do the Blood test, but a. I have a Voodoo3, not an actual Voodoo or Voodoo2, and b. something's gone off with my Win98 installation, and I haven't figured it out yet. Still...

In my blood TX3DFX folder I have 24 3df files, would they have been validly converted with glidos> or are they corrupt still?

Here you are. Have fun. 😁

From the README:

This doesn't seem to work for Windows 2000, and probably wont for Windows XP either.

If your only testing is with Windows 2000 - give CLI2NOP a try on the executable (just a random thought)
showthread.php?threadid=31

Wait 'til Nicht gets a load of this! 😀

I'm happy to report that on my test system of the day:

1Motherboard:  1300 MHz PIV Motherboard and CPU Assembly  
2BIOS: Intel Corp. GB85010A.15A.0028.P09.0103091412 03/09/2001
3Processor:  Intel Pentium 4, 1300 MHz, 100MHz external bus
4Memory:  256MB RDRAM PC800, 71% free resources, 4 memory slots, 2 free (128+128+0+0)
5Hard Drive:  20GB 5M Ultra ATA Hard Drive (FAT32), 19459MB total, 14201MB free, Swap file on C: Min 409600KB, File cache: Max 524288KB
6Hard Drive Controllers: Intel 82801BA Ultra ATA Storage Controller
7Monitor:  EV910 19 Monitor(18 Viewable)
8Video Card: NVIDIA RIVA TNT2 Model 64, 32 MB
9Monitor: Gateway EV910
10CD-ROM: LG CD-ROM CRD-8483B 20x Minimum/48x Maximum IDE CD-ROM
11Zip Drive:  Internal 3.5 IOMEGA 250MB Zip IDE
12Sound Card:  Media
13Creative Technology Creative Sound Blaster AudioPCI 128D
14Network Card:  3Com EtherLink 10/100 PCI For Complete PC Management NIC (3C905C-TX)
15Keyboard:  Keyboard US 104 PS2         
16Mouse:  Logitech PS/2 Wheel Mouse
17Floppy Drive:  3.5 1.44 MB Floppy Diskette Drive 
18Operating System: Microsoft Windows 98 Second Edition (Windows 98 4.10.2222 A )
19Browser: MSIE 6.0; T312461

Whose setup I can't change, BTW (Hyper Technologies Inc. Deep Freeze, http://www.deepfreezeusa.com)

After following Paul's instructions, Blood One Whole Unit (DOS Glide) ran fine! (if a bit slow - probably the graphics card). Tested at 800x600.

Great work, Paul!

(Hm, you could simplify some of that if you let GliDOS alter blood.ini's settings and auto-generate the Blood.bat...)

Stiletto wrote:

Wait 'til Nicht gets a load of this!

I downloaded Paul's files on a whim. Was stunned when it didn't lock up. Wasn't exactly viewable though. But the "mechanics" were working. I recognized some of the graphics, but it appears that there's no "erasing" of any graphics. So everything is a blur. Interesting to see running though, as I could never get it to work before at all.

BTW, this was on Win98SE. XP does nothing with it, as expected.

I ran blood on my winXP it performed fine but the graphics are still wrong? (at least it doesnt crash though)

maybe paul coul add a selection between 2 diferent color modes to solve the problem, but makeing glidos run ARGB color might just be too much to do