It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Hey all,

Thought I would share how to make One Unit Whole Blood the entire series run in its resolution of 1280x1024 smooth.

First off youll need the game obviously.

So download the installer and install it all.

Next go here and download the new version of DosBox: http://ykhwong.x-y.net/xe/dosbox_data/143

Next extract that over the dosbox version that was installed with your game.

Now goto your game's directory and search for the files called, "dosboxBlood.conf", "dosboxBlood_addon.conf"

Open them and then take the following and copy and paste it in them over what is already in them and then save the files.
fullscreen=true
fulldouble=false
fullresolution=desktop
windowresolution=original
output=surface
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-SVN-Daum.map
pixelshader=4xSoft_PS3.0.fx
usescancodes=false
overscan=0

[dosbox]
# language: Select another language file.
# machine: The type of machine DOSBox tries to emulate.
# Note that svga_s3 is significantly faster than svga_s3_full for standard-VGA games, but may break a few older games.
# Possible values: hercules, cga, cga_mono, tandy, pcjr, ega, vgaonly, svga_s3, svga_s3_full, svga_et3000, svga_et4000, svga_paradise, vesa_nolfb, vesa_oldvbe, amstrad.
# vmemsize: Amount of video memory in megabytes.
# The maximum resolution and color depth the svga_s3 will be able to display
# is determined by this value.
# 0: 512k (800x600 at 256 colors)
# 1: 1024x768 at 256 colors or 800x600 at 64k colors
# 2: 1600x1200 at 256 colors or 1024x768 at 64k colors or 640x480 at 16M colors
# 4: 1600x1200 at 64k colors or 1024x768 at 16M colors
# 8: up to 1600x1200 at 16M colors
# For build engine games, use more memory than in the list above so it can
# use triple buffering and thus won't flicker.
#
# captures: Directory where things like wave, midi, screenshot get captured.
# memsize: Amount of memory DOSBox has in megabytes.
# This value is best left at its default to avoid problems with some games,
# though few games might require a higher value.
# There is generally no speed advantage when raising this value.
# memsizekb: Amount of memory DOSBox has in kilobytes.
# This value should normally be set to 0.
# If nonzero, overrides the memsize parameter.
# Finer grained control of total memory may be useful in
# emulating ancient DOS machines with less than 640KB of
# RAM or early 386 systems with odd extended memory sizes.
#
# memalias: Memory aliasing emulation, in number of valid address bits.
# . Many 386/486 class motherboards and processors prior to 1995
# suffered from memory aliasing for various technical reasons. If the software you are
# trying to run assumes aliasing, or otherwise plays cheap tricks with paging,
# enabling this option can help. Note that enabling this option can cause slight performance degredation. Set to 0 to disable.
# Recommended values when enabled:
# 24: 16MB aliasing. Common on 386SX systems (CPU had 24 external address bits)
# or 386DX and 486 systems where the CPU communicated directly with the ISA bus (A24-A31 tied off)
# 26: 64MB aliasing. Some 486s had only 26 external address bits, some motherboards tied off A26-A31
#

language=
machine=svga_s3
vmemsize=2
captures=capture
memsize=64
memsizekb=0
memalias=0

[render]
# frameskip: How many frames DOSBox skips before drawing one.
# aspect: Do aspect correction, if your output method doesn't support scaling this can slow things down!.
# linewise: Draw the display line by line. Needed for certain special graphics effects in games and demos. Can be changed at runtime but will be put in effect at the next mode switch.
# char9: Allow 9-pixel wide text mode fonts.
# multiscan: Set this value to true to allow zooming gfx effects used in demos. It will disable several options such as scalers though.
# scaler: Scaler used to enlarge/enhance low resolution modes. If 'forced' is appended,
# then the scaler will be used even if the result might not be desired.
# Possible values: none, normal2x, normal3x, advmame2x, advmame3x, advinterp2x, advinterp3x, hq2x, hq3x, 2xsai, super2xsai, supereagle, tv2x, tv3x, rgb2x, rgb3x, scan2x, scan3x, hardware2x, hardware3x.
# autofit: Best fits image to window
# - Intended for output=direct3d, fullresolution=original, aspect=true

frameskip=0
aspect=false
linewise=false
char9=false
multiscan=false
scaler=xbrz
autofit=true
Next search for the file called, "BLOOD.CFG"

Open it

Change the ScreenWidth = to be 1280

Then

Change ScreenHeight = to be 1024

Then

Save the file

Then

Launch the game and enjoy.

Here is sum pics of what it looks like when playing.

+ look at pic 2. Did ya know you the game does support 3rd person mode not jest 1st person?
Attachments:
blood_008.png (189 Kb)
blood_009.png (215 Kb)
Post edited February 25, 2013 by Stixsmaster
avatar
Stixsmaster: Hey all,

Thought I would share how to make One Unit Whole Blood the entire series run in its resolution of 1280x1024 smooth.
Works great, thanks for sharing.
avatar
Stixsmaster: Hey all,

Thought I would share how to make One Unit Whole Blood the entire series run in its resolution of 1280x1024 smooth.
avatar
DustyStyx: Works great, thanks for sharing.
I will test this later with the 3dfx patch if possible.
avatar
DustyStyx: Works great, thanks for sharing.
avatar
Stixsmaster: I will test this later with the 3dfx patch if possible.
I remeber that the original 3dfx patch only supported 640*480

Same goes with the Shadow Warrior one.
Post edited March 25, 2013 by tejozaszaszas
Well, fps is still crap (has difficulty to maintain 40 fps on the settings you recommend in 1024x768) and there are numerous graphical glitches. You know why I can emulate PS2 games on a smooth 60 fps and why I can't play BUILD games in DosBox? Because DOSBox is horrendous.
It's not fault of Dosbox either, even in native DOS or older Windowses, BUILD games are very demanding if running above 640x480. 800x600 is magical border where it may cause framerate drops and other things to you. ;-)

Remeber, this is BUILD, Dos executables, NOT Doom or Wolf engines that were less resources consuming or has very strict limits. Especially Blood and Shadow Warrior are BUILD monstrosities, like kind of limit removing, demanding as hell but worth every single resource and memory they eat up. ;-)
Post edited May 02, 2013 by HenitoKisou
Well I was a bit lazy and did not even look at the settings posted while copy pasting stuff. There were a lot of things wrong with it, I highly doubt the OP was close to the 100 fps he was talking about.

Ironed out some things and could manage to set up the game correctly. Graphical glitches are gone and the fps is a solid 70 now in 800x600.

Anyway DOSBox is still bad, it's not Build's fault, back in the day it ran great for me on DOS, granted I had a good machine for the time. Back to DOSBox: it completely destroys the old Prince of Persia games for example, PoP 2 is unplayable. This SVN build looks promising, I'll try them later on this, however I have to say that the general state of DOSBox saddens me.
Post edited May 02, 2013 by Sance231
avatar
Sance231: You know why I can emulate PS2 games on a smooth 60 fps and why I can't play BUILD games in DosBox? Because DOSBox is horrendous.
No, build engine is horrendous. It was fine back then when it was fine-tuned to actual DOS and computer hardware, but it's funny that vast majority of stuff I try to launch via DosBox runs just fine, with some notable exceptions. So, where do you think fault lies, in DosBox, or in those notable exceptions? I do think that the answer is quite clear. At any rate, DosBox itself is quite CPU intensive for obvious reasons (CPU has to completely emulate a very dated machine and an OS running it), and of course Microsoft has never released source code for DOS, therefore a lot of what is done in software like DosBox has to be based on what we know and some guesswork. Guess how that helps applications that were not quite coded adhering to standards, like build engine.
avatar
Sance231: You know why I can emulate PS2 games on a smooth 60 fps and why I can't play BUILD games in DosBox? Because DOSBox is horrendous.
avatar
Fenixp: No, build engine is horrendous. It was fine back then when it was fine-tuned to actual DOS and computer hardware, but it's funny that vast majority of stuff I try to launch via DosBox runs just fine, with some notable exceptions. So, where do you think fault lies, in DosBox, or in those notable exceptions? I do think that the answer is quite clear. At any rate, DosBox itself is quite CPU intensive for obvious reasons (CPU has to completely emulate a very dated machine and an OS running it), and of course Microsoft has never released source code for DOS, therefore a lot of what is done in software like DosBox has to be based on what we know and some guesswork. Guess how that helps applications that were not quite coded adhering to standards, like build engine.
Look, I see the huge amount of work put into DosBOX and I appreciate it but there is a reason why the latest version is called 0.74. As an emulator it's good because most games run on a playable level without graphical glitches but as a software that is used with official digital releases of old games it's unbelievably bad.

The Build engine is not horrendous, it's only the "high end" of DOS game engines that had no problems running fast on the machines of 1997-1998. The problem with DOSBox is that the emulation is generally too slow and unresponsive for these games. This is what should be fixed, the devs should not sit on a DOSBox version for years and disregard questions about new releases in an arrogant fashion, instead improving support for Build games should be top priority. SVN releases are usually much better though and that's a good thing.
avatar
Sance231: The Build engine is not horrendous, it's only the "high end" of DOS game engines that had no problems running fast on the machines of 1997-1998.
Well... DosBox is open source. You can't really fault devs for slow development as they don't demand a single dime from you in return - all you can do is to say "Well, DosBox is slow, I won't use it."

That being said, it's funny that Quake engine works perfectly fine with my DosBox. Clearly, build engine is not more advanced than quake engine. But you know what quake engine is? Incredibly well coded, following most standards.
avatar
Sance231: The Build engine is not horrendous, it's only the "high end" of DOS game engines that had no problems running fast on the machines of 1997-1998.
avatar
Fenixp: Well... DosBox is open source. You can't really fault devs for slow development as they don't demand a single dime from you in return - all you can do is to say "Well, DosBox is slow, I won't use it."
But if I want to play Blood for example on my Win 7 machine I just can't do that .:) I think that for the sake of creating a good DOS emulator things should change: some company (GOG?) should pay those guys for their work and make them develop this thing full time. Anyway they don't get some amount of money from some sources? GOG and Steam uses their software so they should get something in exchange I guess.
Post edited May 03, 2013 by Sance231
avatar
Fenixp: Well... DosBox is open source. You can't really fault devs for slow development as they don't demand a single dime from you in return - all you can do is to say "Well, DosBox is slow, I won't use it."
avatar
Sance231: But if I want to play Blood for example on my Win 7 machine I just can't do that .:) I think that for the sake of creating a good DOS emulator things should change: some company (GOG?) should pay those guys for their work and make them develop this thing full time. Anyway they don't get some amount of money from some sources? GOG and Steam uses their software so they should get something in exchange I guess.
DOSBox.com has a respectably sized donation button....

There is also a link to a recent DOSBox development interview Sourceforge published when DOSBox was granted project of the month last January (2013). It has a few tidbits about current DOSBox development.
avatar
Sance231: But if I want to play Blood for example on my Win 7 machine I just can't do that .:) I think that for the sake of creating a good DOS emulator things should change: some company (GOG?) should pay those guys for their work and make them develop this thing full time. Anyway they don't get some amount of money from some sources? GOG and Steam uses their software so they should get something in exchange I guess.
avatar
DustyStyx: DOSBox.com has a respectably sized donation button....

There is also a link to a recent DOSBox development interview Sourceforge published when DOSBox was granted project of the month last January (2013). It has a few tidbits about current DOSBox development.
Well support them if you want but personally I'd be glad if I could support them through buying games that use their software. First, you'll never make a salary from donations. Second, the "development is slow but still there" comment from that interview totally discourages me from giving them money anyway. There are so many things wrong with their product, we have badass CPUs, unlimited amount of RAM and killer GPUs these days, yet we can't play freakin' DOS games properly.

As for Blood all I can do is hope for improvements: Duke 3D was re-released in a superb state in the Megaton Edition (it was hard to surpass eDuke32 but Devolver Digital really did it and we don't even have half the features they are planning yet), Shadow Warrior is also happening, at some point I'm sure we'll get Blood too. If the first two Build re-releases are successful Atari will do it and allow Devolver to do something with Blood I think.
Post edited May 03, 2013 by Sance231
avatar
DustyStyx: DOSBox.com has a respectably sized donation button....

There is also a link to a recent DOSBox development interview Sourceforge published when DOSBox was granted project of the month last January (2013). It has a few tidbits about current DOSBox development.
avatar
Sance231: Well support them if you want but personally I'd be glad if I could support them through buying games that use their software. First, you'll never make a salary from donations. Second, the "development is slow but still there" comment from that interview totally discourages me from giving them money anyway. There are so many things wrong with their product, we have badass CPUs, unlimited amount of RAM and killer GPUs these days, yet we can't play freakin' DOS games properly.

As for Blood all I can do is hope for improvements: Duke 3D was re-released in a superb state in the Megaton Edition (it was hard to surpass eDuke32 but Devolver Digital really did it and we don't even have half the features they are planning yet), Shadow Warrior is also happening, at some point I'm sure we'll get Blood too. If the first two Build re-releases are successful Atari will do it and allow Devolver to do something with Blood I think.
You are singing a song that is over a decade old. Unfortunately, until the Blood source code is released we are kinda stuck with either emulation or engine ports (BloodTC, Transfusion, XL Engine, zBlood, etc.) Engine ports suffer because "it's not Blood", and the community fractures over which port is better. They are also legally dubious because they either breach copyright and DRM directly, or expect the end user to do it themselves. (Transfusion being the exception because of the quitclaim Atari granted to the game media)

Emulation is nice in that it is legally sound and will support will only get better as time goes on. You can already run Blood at 100+ FPS if you know what you are doing with VirtualBox and FreeDOS. But emulation suffers because, although the game is supported, there is limited growth in community development because of the limited nature of what Build circa 1997 can support.

No, you can't just run Blood on Windows 7 but I mentioned the interview because there was reference to Wine on Windows. This would the the third option of developing an API that would allow DOS and older Win16/32 programs to run on the native hardware (rather than through emulation). Unfortunately it still suffers from the game being relatively static.
avatar
Sance231: Well support them if you want but personally I'd be glad if I could support them through buying games that use their software. First, you'll never make a salary from donations. Second, the "development is slow but still there" comment from that interview totally discourages me from giving them money anyway. There are so many things wrong with their product, we have badass CPUs, unlimited amount of RAM and killer GPUs these days, yet we can't play freakin' DOS games properly.

As for Blood all I can do is hope for improvements: Duke 3D was re-released in a superb state in the Megaton Edition (it was hard to surpass eDuke32 but Devolver Digital really did it and we don't even have half the features they are planning yet), Shadow Warrior is also happening, at some point I'm sure we'll get Blood too. If the first two Build re-releases are successful Atari will do it and allow Devolver to do something with Blood I think.
avatar
DustyStyx: You are singing a song that is over a decade old. Unfortunately, until the Blood source code is released we are kinda stuck with either emulation or engine ports (BloodTC, Transfusion, XL Engine, zBlood, etc.) Engine ports suffer because "it's not Blood", and the community fractures over which port is better. They are also legally dubious because they either breach copyright and DRM directly, or expect the end user to do it themselves. (Transfusion being the exception because of the quitclaim Atari granted to the game media)

Emulation is nice in that it is legally sound and will support will only get better as time goes on. You can already run Blood at 100+ FPS if you know what you are doing with VirtualBox and FreeDOS. But emulation suffers because, although the game is supported, there is limited growth in community development because of the limited nature of what Build circa 1997 can support.

No, you can't just run Blood on Windows 7 but I mentioned the interview because there was reference to Wine on Windows. This would the the third option of developing an API that would allow DOS and older Win16/32 programs to run on the native hardware (rather than through emulation). Unfortunately it still suffers from the game being relatively static.
Well things look a bit better than before for Blood I think: at least now we know Jace Hall has the source code and wants to re-release the game, at some point Atari will jump on the boat too I think.