VOGONS

Search

Common searches

Peculiar resolution problem

Topic actions

Reply 20 of 32, by 2mg

Posted on 
User metadata
Rank Member
Rank
Member
truth5678 wrote:

It seems that you do not enjoy troubleshooting problems since I offered openglnb and openglhq methods, too, but you hadn't tried those.

The scaling Output type doesn't really concern me on 800x600 and above - all OGLs at that point are indiscernable. The very idea of stretching a low rez into a high one, no matter how good it is, will never be as nice as say 1024x768 (un)stretched, or 1600x1200 unstretched/fit to desktop rez.

truth5678 wrote:

I also do not have the problems with 3dfx mode as you showed above. If you do not wish to test that further because of probable memory leaks, that is reasonable, but I ran higher resolution modes fine. Dege, the creator of the above glide wrapper, also generously offered advice on setting up a glide wrapper with the game; I wouldn't dismiss his advice without appreciation and trial runs.

I just can't get it looking either any different, or get above 800x600 - which looks the same as D3D 800x600, which does the same as OGL 800x600... I think it's the unfinished 3dfx alpha exe. If you can get 102x768 or anything above, please say so which rez is working for you so I can try.

truth5678 wrote:

I'll repeat the above post which you seem to have partly ignored, as 3dfx was only one idea. The other is to run at 800x600 and scale with openglnb (and openglhq). Also, I hope you ensured the core/cycles settings mentioned above. Then, if you'd like to verify the cycles drop, try Quake 1 to troubleshoot. I have had the same frame drops and the theory has been explained. The next step is to run an experiment to prove the theory (frame drops versus resolution; build engine inefficiencies at scaling), if you wish to do that, then one idea is to test with Quake 1 (or Duke Nukem 3d, a build engine game, in a real DOS system)..

I'll try Duke, I have it buried somewhere + it's Build. I'm running latest GLQuake 1 on W7 as it is 😉

Also, I am playing on 800x60 fit to screen with Fullscreenresolution=Desktop, Scaler=none. It's basically the same as 800x600 (Hardware)NormalX2 - that's not the issue here. Scaling isn't the issue here at all. In fact it's so insignificant, because playing with Fullscreenresolution=Original, Scaler=none on 1024x768, so there is absolutely no stress load on the CPU other than rendering, still causes cycle the same variances. The very point is to get as high as possible a native resolution with stable FPS, stretching as a potential slowdown comes later. I've tried 320x200 with HQ3x and 1600x1200 Original and got the same results - the higher native rez the funkier the cycles.

truth5678 wrote:

Another test is to starve dosbox of cycles, enter a small number of cycles, and then run the Blood game at 640x480, and test for the slowdowns. However, this lower resolution may not reveal the inefficiencies. Furthermore, Hal replied and he's an expert on this matters, so if he suggests resolution as a major factor, that shouldn't be dismissed. He wrote much emulation of the video cards, so the next step, to restate, is to run your tests and report the results. 😀

I did, I've wrote results in one of my threads. It comes down that I must use (and it's on the DOSBox games page) Dynamic core with not going below 400-500k, and not above 1000k. The problem is that is a huge space where my actual cycles jump up and down.

truth5678 wrote:

As also mentioned above, you cannot set cycles to higher than the "max" amount. If you are setting cycles higher than your machine is capable, then you will introduce another cause for video and game stuttering. Set at max or a setting which allows a 5% reduction from max. Also, try setting all audio to off in emulation and game to test whether audio has any role in video slowdowns during high game activity.

I know - please read my last post, last paragraph in Italics. The very answer pops immediately into the head - of course my max cycles are 500k in combat, and 1000k out of it, BUT then I'd have one of my CPU cores maximally used at those 500k cycles, which is not the case, so obviously my CPU can provide more actual cycles (and the max itself) than 500k in combat, but DOSBox won't work like that!

Gamecollector wrote:
Have tested, 800x600 is supported. Change the resolution from the game menu. 1024x768 - qtd with "standard videomode failed". P. […]
Show full quote
2mg wrote:

nGlide on the other hand provides 640x480 MAX

Have tested, 800x600 is supported. Change the resolution from the game menu.
1024x768 - qtd with "standard videomode failed".
P.S. Default resolution (512x384) is bugged in nGlide 1.02, so - run the game with "set BUILD_640x480=1".

Which supports my claim (and what I've read around) about Blood 3dfx.

truth5678 wrote:

I tested the game using all available VESA modes, including manual configuration to 1024x768 and 1280x1024, and they run full speed in dosbox. The host CPU is a slower core2duo system. I observed no slowdowns with cycles=max. Modified the cycles settings to 250,000 and 1024x768 ran at full speed. Used Ykhwong's build for all tests.

Wow, 250k? Way below mine. OK, maybe I'm pushing it for trying to get 50-60 FPS, but in the end, it's about drops from 60 to 27 FPS that bugs me.

truth5678 wrote:

Paste your dosbox.conf and blood.cfg settings in a "Code" text box. This option is in the Full Editor when you are replying to messages here at Vogons. There are many dosbox settings and it would be important to verify your video/audio settings, including sb16 irq. Also, are you running Windows 8.1 for the host OS? If so, it is best to test dosbox in another host.

Incoming!

Reply 21 of 32, by 2mg

Posted on 
User metadata
Rank Member
Rank
Member

DOSBox Daum latest Win7 x64 3.6Ghz i5 8GB Ram with OUWB Launcher (same results if I do everything manually, even without sound)

# This is the configuration file for DOSBox SVN-Daum. (Please use the latest version of DOSBox)
# Lines starting with a # are comment lines and are ignored by DOSBox.
# They are used to (briefly) document the effect of each option.

[sdl]
#       fullscreen: Start dosbox directly in fullscreen. (Press ALT-Enter to go back)
#       fulldouble: Use double buffering in fullscreen. It can reduce screen flickering, but it can also result in a slow DOSBox.
#   fullresolution: What resolution to use for fullscreen: original, desktop or a fixed size (e.g. 1024x768).
#                     Using your monitor's native resolution with aspect=true might give the best results.
#                     If you end up with small window on a large screen, try an output different from surface.
# windowresolution: Scale the window to this size IF the output device supports hardware scaling.
#                     (output=surface does not!)
#           output: What video system to use for output.
#                   Possible values: surface, overlay, opengl, openglnb, openglhq, ddraw, direct3d.
#         autolock: Mouse will automatically lock, if you click on the screen. (Press CTRL-F10 to unlock)
#      sensitivity: Mouse sensitivity.
#      waitonerror: Wait before closing the console if dosbox has an error.
#         priority: Priority levels for dosbox. Second entry behind the comma is for when dosbox is not focused/minimized.
output=direct3d
#                   Possible values: lowest, lower, normal, higher, highest, pause.
#       mapperfile: File used to load/save the key/event mappings from. Resetmapper only works with the default value.
#      pixelshader: Pixelshader program (effect file must be in Shaders subdirectory). If 'forced' is appended,
#                   then the shader will be used even if the result might not be desired.
#     usescancodes: Avoid usage of symkeys, might not work on all operating systems.
#         overscan: Width of overscan border (0 to 10). (works only if output=surface)
fullscreen=true
fulldouble=true
fullresolution=desktop
windowresolution=original
output=direct3d
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper.txt
pixelshader=none
usescancodes=true
overscan=0

[dosbox]
#                    language: Select another language file.
#                     machine: The type of machine DOSBox tries to emulate.
#                              Possible values: hercules, cga, cga_mono, tandy, pcjr, ega, vgaonly, svga_s3, 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.
# mainline compatible mapping: If set, arrange private areas, UMBs, and DOS kernel structures by default in the same way the mainline branch would do it.
#                              If cleared, these areas are allocated dynamically which may improve available memory and emulation accuracy.
#                              If your DOS game breaks under DOSBox-X but works with mainline DOSBox setting this option may help.
#          adapter rom is ram: Map adapter ROM as RAM (mainline DOSBox 0.74 behavior). When clear, unused adapter ROM is mapped out
#           private area size: Set DOSBox-X private memory area size. This area contains private memory structures used by the DOS kernel.
…Show last 515 lines
#                              It is discarded when you boot into another OS. Mainline DOSBox uses 32KB. Testing shows that it is possible
#                              to run DOSBox with as little as 4KB. If DOSBox-X aborts with error "not enough memory for internal tables"
#                              then you need to increase this value.
#                     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
#                              
#      vga bios size override: VGA BIOS size override. Override the size of the VGA BIOS (normally 32KB in compatible or 12KB in non-compatible).
#                   forcerate: Force the VGA framerate to a specific value(ntsc, pal, or specific hz), no matter what
#                     cgasnow: When machine=cga, determines whether or not to emulate CGA snow
#                    pit hack: If set, demo/game-specific hacks are applied to PIT timer emulation to help
#                              stabilize the demo and run more reliably. Valid values are:
#                                'project_angel_demo'            If you intend to run the Project Angel demo, use this
#                                                                setting. The PIT timer is forced to one of two values
#                                                                to resolve hangups, timing issues, music skipping on
#                                                                video mode changes, and VGA tearlines.
#                                'pc_speaker_as_timer'           A few early DOS demos apparently like to use PIT 2 as
#                                                                a timer source (where normally PIT 2 is used to generate
#                                                                a square wave to drive the PC speaker). If the demo you
#                                                                are running seems to run at half the normal speed for no
#                                                                logical reason, try this hack. Demos that need this hack:
#                                                                   - Impact Studios, Legend
#                              Possible values: , project_angel_demo, pc_speaker_as_timer.
language=
machine=svga_s3
vmemsize=16
captures=capture
mainline compatible mapping=true
adapter rom is ram=false
private area size=32768
memsize=63
memsizekb=0
memalias=0
vga bios size override=0
forcerate=
cgasnow=true
pit hack=

[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.
# doublescan: If set, doublescanned output emits two scanlines for each source line, in the
#             same manner as the actual VGA output (320x200 is rendered as 640x400 for example).
#             If clear, doublescanned output is rendered at the native source resolution (320x200 as 320x200).
#             This affects the raster PRIOR to the software or hardware scalers. Choose wisely.
#             
#     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, normal4x, normal5x, advmame2x, advmame3x, advinterp2x, advinterp3x, hq2x, hq3x, 2xsai, super2xsai, supereagle, tv2x, tv3x, rgb2x, rgb3x, scan2x, scan3x, hardware_none, hardware2x, hardware3x, hardware4x, hardware5x, xbrz.
#    autofit: Best fits image to window
#             - Intended for output=direct3d, fullresolution=original, aspect=true
frameskip=0
aspect=true
linewise=false
char9=false
doublescan=true
scaler=none
autofit=false

[vsync]
# vsyncmode: Synchronize vsync timing to the host display. Requires calibration within dosbox.
#            Possible values: off, on, force, host.
# vsyncrate: Vsync rate used if vsync is enabled. Ignored if vsyncmode is set to host (win32).
#            Possible values:.
vsyncmode=host
vsyncrate=60

[cpu]
#             core: CPU Core used in emulation. auto will switch to dynamic if available and
#                   appropriate.
#                   Possible values: auto, dynamic, normal, full, simple.
#          cputype: CPU Type used in emulation. auto emulates a 486 which tolerates Pentium instructions.
#                   Possible values: auto, 386, 486, pentium, 386_prefetch, pentium_mmx.
#           cycles: Amount of instructions DOSBox tries to emulate each millisecond.
#                   Setting this value too high results in sound dropouts and lags.
#                   Cycles can be set in 3 ways:
#                     'auto'          tries to guess what a game needs.
#                                     It usually works, but can fail for certain games.
#                     'fixed #number' will set a fixed amount of cycles. This is what you usually
#                                     need if 'auto' fails (Example: fixed 4000).
#                     'max'           will allocate as much cycles as your computer is able to
#                                     handle.
#                   Possible values: auto, fixed, max.
#          cycleup: Amount of cycles to decrease/increase with keycombos.(CTRL-F11/CTRL-F12)
#        cycledown: Setting it lower than 100 will be a percentage.
# ignore opcode 63: When debugging, do not report illegal opcode 0x63.
#                   Enable this option to ignore spurious errors while debugging from within Windows 3.1/9x/ME
#          apmbios: Emulate Advanced Power Management BIOS calls.
#                   Do not enable if you are running Windows ME.
#       isapnpbios: Emulate ISA Plug & Play BIOS. Enable if using DOSBox to run a PnP aware DOS program or if booting Windows 9x.
#                   Do not disable if Windows 9x is configured around PnP devices, you will likely confuse it.
#        realbig16: Allow the B (big) bit in real mode. If set, allow the DOS program to set the B bit,
#                   then jump to realmode with B still set (aka Huge Unreal mode). Needed for Project Angel.
core=auto
cputype=auto
cycles=max
cycleup=10000
cycledown=10000
ignore opcode 63=true
apmbios=false
isapnpbios=true
realbig16=false

[keyboard]
#       aux: Enable emulation of the 8042 auxiliary port. PS/2 mouse emulation requires this to be enabled.
#            You should enable this if you will be running Windows ME or any other OS that does not use the BIOS to receive mouse events.
# auxdevice: Type of PS/2 mouse attached to the AUX port
#            Possible values: none, 2button, 3button, intellimouse, intellimouse45.
aux=false
auxdevice=intellimouse

[pci]
# voodoo: Enable VOODOO support.
#         Possible values: false, software, opengl, auto.
voodoo=auto

[mixer]
#    nosound: Enable silent mode, sound is still emulated though.
# swapstereo: Swaps the left and right stereo channels.
#       rate: Mixer sample rate, setting any device's rate higher than this will probably lower their sound quality.
#             Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
#  blocksize: Mixer block size, larger blocks might help sound stuttering but sound will also be more lagged.
#             Possible values: 1024, 2048, 4096, 8192, 512, 256.
#  prebuffer: How many milliseconds of data to keep on top of the blocksize.
nosound=false
swapstereo=false
rate=44100
blocksize=512
prebuffer=40

[midi]
#              mpu401: Type of MPU-401 to emulate.
#                      Possible values: intelligent, uart, none.
#          mididevice: Device that will receive the MIDI data from MPU-401.
#                      Possible values: default, win32, alsa, oss, coreaudio, coremidi, mt32, synth, timidity, none.
#          midiconfig: Special configuration options for the device driver. This is usually the id of the device you want to use.
#                        or in the case of coreaudio, you can specify a soundfont here.
#                        When using a Roland MT-32 rev. 0 as midi output device, some games may require a delay in order to prevent 'buffer overflow' issues.
#                        In that case, add 'delaysysex', for example: midiconfig=2 delaysysex
#                        See the README/Manual for more details.
# mt32.reverse.stereo: Reverse stereo channels for MT-32 output
#                      Possible values: off, on.
#        mt32.verbose: MT-32 debug logging
#                      Possible values: off, on.
#         mt32.thread: MT-32 rendering in separate thread
#                      Possible values: off, on.
#            mt32.dac: MT-32 DAC input emulation mode
#                      Nice = 0 - default
#                      Produces samples at double the volume, without tricks.
#                      Higher quality than the real devices
#                      
#                      Pure = 1
#                      Produces samples that exactly match the bits output from the emulated LA32.
#                      Nicer overdrive characteristics than the DAC hacks (it simply clips samples within range)
#                      Much less likely to overdrive than any other mode.
#                      Half the volume of any of the other modes, meaning its volume relative to the reverb
#                      output when mixed together directly will sound wrong. So, reverb level must be lowered.
#                      Perfect for developers while debugging :)
#                      
#                      GENERATION1 = 2
#                      Re-orders the LA32 output bits as in early generation MT-32s (according to Wikipedia).
#                      Bit order at DAC (where each number represents the original LA32 output bit number, and XX means the bit is always low):
#                      15 13 12 11 10 09 08 07 06 05 04 03 02 01 00 XX
#                      
#                      GENERATION2 = 3
#                      Re-orders the LA32 output bits as in later geneerations (personally confirmed on my CM-32L - KG).
#                      Bit order at DAC (where each number represents the original LA32 output bit number):
#                      15 13 12 11 10 09 08 07 06 05 04 03 02 01 00 14
#                      
#                      Possible values: 0, 1, 2, 3, auto.
#    mt32.reverb.mode: MT-32 reverb mode
#                      Possible values: 0, 1, 2, 3, auto.
#    mt32.reverb.time: MT-32 reverb decaying time
#                      Possible values: 0, 1, 2, 3, 4, 5, 6, 7.
#   mt32.reverb.level: MT-32 reverb level
#                      Possible values: 0, 1, 2, 3, 4, 5, 6, 7.
#       mt32.partials: MT-32 max partials allowed (0-256)
mpu401=intelligent
mididevice=win32
midiconfig=
mt32.reverse.stereo=off
mt32.verbose=off
mt32.thread=off
mt32.dac=auto
mt32.reverb.mode=auto
mt32.reverb.time=5
mt32.reverb.level=3
mt32.partials=32

[sblaster]
#       sbtype: Type of Soundblaster to emulate. gb is Gameblaster.
#               Possible values: sb1, sb2, sbpro1, sbpro2, sb16, sb16vibra, gb, none.
#       sbbase: The IO address of the soundblaster.
#               Possible values: 220, 240, 260, 280, 2a0, 2c0, 2e0, 300.
#          irq: The IRQ number of the soundblaster.
#               Possible values: 7, 5, 3, 9, 10, 11, 12.
#          dma: The DMA number of the soundblaster.
#               Possible values: 1, 5, 0, 3, 6, 7.
#         hdma: The High DMA number of the soundblaster.
#               Possible values: 1, 5, 0, 3, 6, 7.
#      sbmixer: Allow the soundblaster mixer to modify the DOSBox mixer.
#      oplmode: Type of OPL emulation. On 'auto' the mode is determined by sblaster type.
#               All OPL modes are Adlib-compatible, except for 'cms'. sbtype=none
#               together with oplmode=cms will emulate a Gameblaster.
#               Possible values: auto, cms, opl2, dualopl2, opl3, none, hardware, hardwaregb.
#       oplemu: Provider for the OPL emulation. compat might provide better quality (see oplrate as well).
#               Possible values: default, compat, fast.
#      oplrate: Sample rate of OPL music emulation. Use 49716 for highest quality (set the mixer rate accordingly).
#               Possible values: 44100, 49716, 48000, 32000, 22050, 16000, 11025, 8000.
# hardwarebase: base address of the real hardware soundblaster:
#               210,220,230,240,250,260,280
#     goldplay: Enable goldplay emulation.
sbtype=sb16vibra
sbbase=220
irq=5
dma=1
hdma=5
sbmixer=true
oplmode=auto
oplemu=compat
oplrate=44100
hardwarebase=220
goldplay=false

[gus]
#      gus: Enable the Gravis Ultrasound emulation.
#  gusrate: Sample rate of Ultrasound emulation.
#           Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
#  gusbase: The IO base address of the Gravis Ultrasound.
#           Possible values: 240, 220, 260, 280, 2a0, 2c0, 2e0, 300.
#   gusirq: The IRQ number of the Gravis Ultrasound.
#           Possible values: 5, 3, 7, 9, 10, 11, 12.
#   gusdma: The DMA channel of the Gravis Ultrasound.
#           Possible values: 3, 0, 1, 5, 6, 7.
# ultradir: Path to Ultrasound directory. In this directory
#           there should be a MIDI directory that contains
#           the patch files for GUS playback. Patch sets used
#           with Timidity should work fine.
gus=false
gusrate=44100
gusbase=240
gusirq=5
gusdma=3
ultradir=C:\ULTRASND

[innova]
#     innova: Enable the Innovation SSI-2001 emulation.
# samplerate: Sample rate of Innovation SSI-2001 emulation
#             Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
#    sidbase: SID base port (typically 280h).
#             Possible values: 240, 220, 260, 280, 2a0, 2c0, 2e0, 300.
#    quality: Set SID emulation quality level (0 to 3).
#             Possible values: 0, 1, 2, 3.
innova=false
samplerate=22050
sidbase=280
quality=0

[speaker]
#    pcspeaker: Enable PC-Speaker emulation.
#       pcrate: Sample rate of the PC-Speaker sound generation.
#               Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
#        tandy: Enable Tandy Sound System emulation. For 'auto', emulation is present only if machine is set to 'tandy'.
#               Possible values: auto, on, off.
#    tandyrate: Sample rate of the Tandy 3-Voice generation.
#               Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
#       disney: Enable Disney Sound Source emulation. (Covox Voice Master and Speech Thing compatible).
#     ps1audio: Enable PS1 audio emulation.
#               Possible values: on, off.
# ps1audiorate: Sample rate of the PS1 audio emulation.
#               Possible values: 44100, 48000, 32000, 22050, 16000, 11025, 8000, 49716.
pcspeaker=false
pcrate=22050
tandy=off
tandyrate=22050
disney=false
ps1audio=off
ps1audiorate=22050

[joystick]
# joysticktype: Type of joystick to emulate: auto (default), none,
#               2axis (supports two joysticks),
#               4axis (supports one joystick, first joystick used),
#               4axis_2 (supports one joystick, second joystick used),
#               fcs (Thrustmaster), ch (CH Flightstick).
#               none disables joystick emulation.
#               auto chooses emulation depending on real joystick(s).
#               (Remember to reset dosbox's mapperfile if you saved it earlier)
#               Possible values: auto, 2axis, 4axis, 4axis_2, fcs, ch, none.
#        timed: enable timed intervals for axis. Experiment with this option, if your joystick drifts (away).
#     autofire: continuously fires as long as you keep the button pressed.
#       swap34: swap the 3rd and the 4th axis. can be useful for certain joysticks.
#   buttonwrap: enable button wrapping at the number of emulated buttons.
joysticktype=none
timed=false
autofire=false
swap34=false
buttonwrap=false

[serial]
# serial1: set type of device connected to com port.
#          Can be disabled, dummy, modem, nullmodem, directserial.
#          Additional parameters must be in the same line in the form of
#          parameter:value. Parameter for all types is irq (optional).
#          for directserial: realport (required), rxdelay (optional).
#                           (realport:COM1 realport:ttyS0).
#          for modem: listenport (optional).
#          for nullmodem: server, rxdelay, txdelay, telnet, usedtr,
#                         transparent, port, inhsocket (all optional).
#          Example: serial1=modem listenport:5000
#          Possible values: dummy, disabled, modem, nullmodem, serialmouse, directserial.
# serial2: see serial1
#          Possible values: dummy, disabled, modem, nullmodem, serialmouse, directserial.
# serial3: see serial1
#          Possible values: dummy, disabled, modem, nullmodem, serialmouse, directserial.
# serial4: see serial1
#          Possible values: dummy, disabled, modem, nullmodem, serialmouse, directserial.
serial1=disabled
serial2=disabled
serial3=disabled
serial4=disabled

[printer]
#     printer: Enable printer emulation.
#         dpi: Resolution of printer (default 360).
#       width: Width of paper in 1/10 inch (default 85 = 8.5'').
#      height: Height of paper in 1/10 inch (default 110 = 11.0'').
# printoutput: Output method for finished pages: 
#                png     : Creates PNG images (default)
#                ps      : Creates Postscript
#                bmp     : Creates BMP images (very huge files, not recommend)
#                printer : Send to an actual printer (Print dialog will appear)
#   multipage: Adds all pages to one Postscript file or printer job until CTRL-F2 is pressed.
#     docpath: The path where the output files are stored.
#     timeout: (in milliseconds) if nonzero: the time the page will
#              be ejected automatically after when no more data
#              arrives at the printer.
printer=false
dpi=360
width=85
height=110
printoutput=png
multipage=false
docpath=.
timeout=0

[parallel]
# parallel1: parallel1-3 -- set type of device connected to lpt port.
#            Can be:
#            	reallpt (direct parallel port passthrough),
#            	file (records data to a file or passes it to a device),
#            	printer (virtual dot-matrix printer, see [printer] section)
#            Additional parameters must be in the same line in the form of
#            parameter:value.
#              for reallpt:
#              Windows:
#                realbase (the base address of your real parallel port).
#                  Default: 378
#                ecpbase (base address of the ECP registers, optional).
#              Linux: realport (the parallel port device i.e. /dev/parport0).
#              for file: 
#                dev:<devname> (i.e. dev:lpt1) to forward data to a device,
#                or append:<file> appends data to the specified file.
#                Without the above parameters data is written to files in the capture dir.
#                Additional parameters: timeout:<milliseconds> = how long to wait before
#                closing the file on inactivity (default:500), addFF to add a formfeed when
#                closing, addLF to add a linefeed if the app doesn't, cp:<codepage number>
#                to perform codepage translation, i.e. cp:437
#              for printer:
#                printer still has it's own configuration section above.
# parallel2: see parallel1
# parallel3: see parallel1
#    dongle: Enable dongle
parallel1=disabled
parallel2=disabled
parallel3=disabled
dongle=false

[glide]
#  glide: Enable glide emulation: true,false,emu.
#    lfb: LFB access: full,full_noaux,read,read_noaux,write,write_noaux,none.
#         OpenGlide does not support locking aux buffer, please use _noaux modes.
# splash: Show 3dfx splash screen (requires 3dfxSpl2.dll).
glide=false
lfb=full
splash=true

[dos]
#                       xms: Enable XMS support.
#                       ems: Enable EMS support. The default (=true) provides the best
#                            compatibility but certain applications may run better with
#                            other choices, or require EMS support to be disabled (=false)
#                            to work at all.
#                            Possible values: true, emsboard, emm386, false.
#                       umb: Enable UMB support.
#                 umb start: UMB region starting segment
#                   umb end: UMB region last segment
# dynamic kernel allocation: If set, DOS kernel structures are allocated dynamically. If clear, DOS kernel structures are fixed at specific segments (mainline DOSBox behavior)
#          keep umb on boot: If emulating UMBs, keep the UMB around after boot (Mainline DOSBox behavior). If clear, UMB is unmapped when you boot an operating system.
# keep private area on boot: If set, keep the DOSBox private area around after boot (Mainline DOSBox behavior). If clear, unmap and discard the private area when you boot an operating system.
#       private area in umb: If set, keep private DOS segment in upper memory block, usually segment 0xC800 (Mainline DOSBox behavior)
#                            If clear, place private DOS segment at the base of system memory (just below the MCB)
#                 automount: Enable automatic mount.
#                     int33: Enable INT 33H (mouse) support.
#                   biosps2: Emulate BIOS INT 15h PS/2 mouse services
#                            Note that some OS's like Microsoft Windows neither use INT 33h nor
#                            probe the AUX port directly and depend on this BIOS interface exclusively
#                            for PS/2 mouse support. In other cases there is no harm in leaving this enabled
#            keyboardlayout: Language code of the keyboard layout (or none).
#                      dbcs: Enable DBCS table
#              filenamechar: Enable filename char table
#   collating and uppercase: Enable collating and uppercase table
#                     files: Number of file handles available to DOS programs. (equivalent to "files=" in config.sys)
xms=true
ems=true
umb=true
umb start=0
umb end=0
dynamic kernel allocation=false
keep umb on boot=false
keep private area on boot=false
private area in umb=true
automount=true
int33=true
biosps2=true
keyboardlayout=none
dbcs=true
filenamechar=true
collating and uppercase=true
files=127

[ipx]
# ipx: Enable ipx over UDP/IP emulation.
ipx=false

[ne2000]
#  ne2000: Enable Ethernet passthrough. Requires [Win]Pcap.
# nicbase: The base address of the NE2000 board.
#  nicirq: The interrupt it uses. Note serial2 uses IRQ3 as default.
# macaddr: The physical address the emulator will use on your network.
#          If you have multiple DOSBoxes running on your network,
#          this has to be changed for each. AC:DE:48 is an address range reserved for
#          private use, so modify the last three number blocks.
#          I.e. AC:DE:48:88:99:AB.
# realnic: Specifies which of your network interfaces is used.
#          Write 'list' here to see the list of devices in the
#          Status Window. Then make your choice and put either the
#          interface number (2 or something) or a part of your adapters
#          name, e.g. VIA here.
ne2000=false
nicbase=300
nicirq=3
macaddr=AC:DE:48:88:99:AA
realnic=list

[ide, primary]
#         enable: Enable IDE interface
#    int13fakeio: If set, force IDE state change on certain INT 13h commands.
#                 IDE registers will be changed as if BIOS had carried out the action.
#                 If you are running Windows 3.11 or Windows 3.11 Windows for Workgroups
#                 you must enable this option (and use -reservecyl 1) if you want 32-bit
#                 disk access to work correctly in DOSBox.
# int13fakev86io: If set, and int13fakeio is set, certain INT 13h commands will
#                 cause IDE emulation to issue fake CPU I/O traps (GPF) in
#                 virtual 8086 mode and a fake IRQ signal. you must enable this option
#                 if you want 32-bit disk access in Windows 95 to work with DOSBox.
enable=true
int13fakeio=false
int13fakev86io=false

[ide, secondary]
enable=true
int13fakeio=false
int13fakev86io=false

[ide, tertiary]
enable=true
int13fakeio=false
int13fakev86io=false

[ide, quaternary]
enable=true
int13fakeio=false
int13fakev86io=false

[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
@ECHO OFF
mount C "."
imgmount D CDMount/game.inst -t iso
c:
cls
cd Blood
BMOUSE.EXE LAUNCH BLOOD.EXE
exit

BLOOD.CFG

[Setup]
;Setup File for Blood
SetupVersion = "1.10"
; 
; 
[Screen Setup]
; 
; 
;ScreenMode
; - Chained - 0
; - Vesa 2.0 - 1
; - Screen Buffered - 2
; - Tseng optimized - 3
; - Paradise optimized - 4
; - S3 optimized - 5
; - RedBlue Stereo - 7
; - Crystal Eyes - 6
; 
;ScreenWidth passed to engine
; 
;ScreenHeight passed to engine
; 
; 
ScreenMode = 1
ScreenWidth = 800
ScreenHeight = 600
; 
; 
Size = 1
Gamma = 6
[Sound Setup]
; 
; 
FXDevice = 6
MusicDevice = 7
FXVolume = 192
MusicVolume = 144
NumVoices = 32
NumChannels = 2
NumBits = 16
MixRate = 44000
MidiPort = 0x330
BlasterAddress = 0x220
BlasterType = 6
BlasterInterrupt = 5
BlasterDma8 = 1
BlasterDma16 = 5
BlasterEmu = 0x620
ReverseStereo = 0
; 
; 
CDVolume = 144
[KeyDefinitions]
; 
; 
Move_Forward = "Up" "W"
Move_Backward = "Down" "S"
Turn_Left = "Left" "Kpad4"
Turn_Right = "Right" "KPad6"
Turn_Around = "BakSpc" "N/A"
…Show last 209 lines
Strafe = "LAlt" "RAlt"
Strafe_Left = "," "A"
Strafe_Right = "." "D"
Jump = "Space" "/"
Crouch = "LCtrl" "Z"
Run = "LShift" "RShift"
AutoRun = "CapLck" "N/A"
Open = "E" "N/A"
Weapon_Fire = "RCtrl" "N/A"
Weapon_Special_Fire = "X" "N/A"
Aim_Up = "Home" "KPad7"
Aim_Down = "End" "Kpad1"
Aim_Center = "KPad5" "N/A"
Look_Up = "PgUp" "Kpad9"
Look_Down = "PgDn" "Kpad3"
Tilt_Left = "Insert" "Kpad0"
Tilt_Right = "Delete" "Kpad."
Weapon_1 = "1" "N/A"
Weapon_2 = "2" "N/A"
Weapon_3 = "3" "N/A"
Weapon_4 = "4" "N/A"
Weapon_5 = "5" "N/A"
Weapon_6 = "6" "N/A"
Weapon_7 = "7" "N/A"
Weapon_8 = "8" "N/A"
Weapon_9 = "9" "N/A"
Weapon_10 = "0" "N/A"
Inventory_Use = "Enter" "KpdEnt"
Inventory_Left = "[" "N/A"
Inventory_Right = "]" "N/A"
Map_Toggle = "Tab" "N/A"
Map_Follow_Mode = "F" "N/A"
Shrink_Screen = "-" "Kpad-"
Enlarge_Screen = "=" "Kpad+"
Send_Message = "T" "N/A"
See_Coop_View = "K" "N/A"
See_Chase_View = "F7" "N/A"
Mouse_Aiming = "U" "N/A"
Toggle_Crosshair = "I" "N/A"
Next_Weapon = "'" "N/A"
Previous_Weapon = ";" "N/A"
Holster_Weapon = "ScrLck" "N/A"
Show_Opponents_Weapon = "W" "N/A"
BeastVision = "B" "N/A"
CrystalBall = "C" "N/A"
JumpBoots = "J" "N/A"
MedKit = "M" "N/A"
ProximityBombs = "P" "N/A"
RemoteBombs = "R" "N/A"
; 
; 
[Controls]
; 
; 
;Controls
; 
;ControllerType
; - Keyboard                  - 0
; - Keyboard and Mouse        - 1
; - Keyboard and Joystick     - 2
; - Keyboard and Gamepad      - 4
; - Keyboard and External     - 3
; - Keyboard and FlightStick  - 5
; - Keyboard and ThrustMaster - 6
; 
; 
ControllerType = 3
JoystickPort = 0
MouseSensitivity = 45872
ExternalFilename = "BMOUSE.EXE"
EnableRudder = 0
MouseAiming = 0
MouseAimingFlipped = 0
MouseButton0 = "Weapon_Fire"
MouseButtonClicked0 = ""
MouseButton1 = "Weapon_Special_Fire"
MouseButtonClicked1 = ""
MouseButton2 = "Weapon_Special_Fire"
MouseButtonClicked2 = ""
JoystickButton0 = "Weapon_Fire"
JoystickButtonClicked0 = ""
JoystickButton1 = "Strafe"
JoystickButtonClicked1 = "Inventory_Use"
JoystickButton2 = "Run"
JoystickButtonClicked2 = "Jump"
JoystickButton3 = "Open"
JoystickButtonClicked3 = "Crouch"
JoystickButton4 = "Aim_Down"
JoystickButtonClicked4 = ""
JoystickButton5 = ""
JoystickButtonClicked5 = ""
JoystickButton6 = "Aim_Up"
JoystickButtonClicked6 = ""
JoystickButton7 = ""
JoystickButtonClicked7 = ""
MouseAnalogAxes0 = "analog_turning"
MouseDigitalAxes0_0 = ""
MouseDigitalAxes0_1 = ""
MouseAnalogScale0 = 13112
MouseAnalogAxes1 = "analog_moving"
MouseDigitalAxes1_0 = ""
MouseDigitalAxes1_1 = ""
MouseAnalogScale1 = -19665
JoystickAnalogAxes0 = "analog_turning"
JoystickDigitalAxes0_0 = ""
JoystickDigitalAxes0_1 = ""
JoystickAnalogScale0 = 65536
JoystickAnalogAxes1 = "analog_moving"
JoystickDigitalAxes1_0 = ""
JoystickDigitalAxes1_1 = ""
JoystickAnalogScale1 = 65536
JoystickAnalogAxes2 = "analog_strafing"
JoystickDigitalAxes2_0 = ""
JoystickDigitalAxes2_1 = ""
JoystickAnalogScale2 = 65536
JoystickAnalogAxes3 = ""
JoystickDigitalAxes3_0 = "Run"
JoystickDigitalAxes3_1 = ""
JoystickAnalogScale3 = 65536
GamePadDigitalAxes0_0 = "Turn_Left"
GamePadDigitalAxes0_1 = "Turn_Right"
GamePadDigitalAxes1_0 = "Move_Forward"
GamePadDigitalAxes1_1 = "Move_Backward"
; 
; 
TurnSpeed = 92
[Comm Setup]
; 
; 
ComPort = 2
IrqNumber = ~
UartAddress = ~
PortSpeed = 9600
ToneDial = 1
SocketNumber = ~
NumberPlayers = 2
ModemName = ""
InitString = "ATZ"
HangupString = "ATH0=0"
DialoutString = ""
PlayerName = "TECMAN"
RTSName = "BLOOD.RTS"
RTSPath = ".\"
UserPath = ".\"
PhoneNumber = ""
ConnectType = 0
CommbatMacro#0 = "I love the smell of napalm..."
CommbatMacro#1 = "Is that gasoline I smell?"
CommbatMacro#2 = "Ta da!"
CommbatMacro#3 = "Who wants some, huh? Who's next?"
CommbatMacro#4 = "I have something for you."
CommbatMacro#5 = "You just gonna stand there..."
CommbatMacro#6 = "That'll teach ya!"
CommbatMacro#7 = "Ooh, that wasn't a bit nice."
CommbatMacro#8 = "Amateurs!"
CommbatMacro#9 = "Fool! You are already dead."
PhoneName#0 = ""
PhoneNumber#0 = ""
PhoneName#1 = ""
PhoneNumber#1 = ""
PhoneName#2 = ""
PhoneNumber#2 = ""
PhoneName#3 = ""
PhoneNumber#3 = ""
PhoneName#4 = ""
PhoneNumber#4 = ""
PhoneName#5 = ""
PhoneNumber#5 = ""
PhoneName#6 = ""
PhoneNumber#6 = ""
PhoneName#7 = ""
PhoneNumber#7 = ""
PhoneName#8 = ""
PhoneNumber#8 = ""
PhoneName#9 = ""
PhoneNumber#9 = ""
PhoneName#10 = ""
PhoneNumber#10 = ""
PhoneName#11 = ""
PhoneNumber#11 = ""
PhoneName#12 = ""
PhoneNumber#12 = ""
PhoneName#13 = ""
PhoneNumber#13 = ""
PhoneName#14 = ""
PhoneNumber#14 = ""
PhoneName#15 = ""
PhoneNumber#15 = ""
[Options]
Detail = 4
MouseAim = 1
AutoRun = 1
Interpolation = 0
ViewHBobbing = 1
ViewVBobbing = 1
FollowMap = 1
OverlayMap = 0
RotateMap = 0
AimReticle = 1
SlopeTilting = 0
MessageState = 1
MessageCount = 4
MessageTime = 5
MessageFont = 0
AdultContent = 0
AdultPassword = ""
Doppler = 1
ShowWeapon = 0

PS: If my CPU actually couldn't pull high stable cycles, Turbo Button wouldn't provide any boost. But If I click on it, and have cycles=max without limit, oh boy, Superman may have turned the Earth backwards and returned time, but this is a whole new dimension of speed...

Reply 22 of 32, by truth_deleted

Posted on 
User metadata

Excellent! Replace your dosbox.conf with the one below. This file is completely pasted. Also, modify your blood.cfg file with the settings below (this is a partial pasting of its contents). Testing should be with Ykhwong's newest dosbox build. It should work perfectly in-game, otherwise please test on a 32-bit Windows platform to verify there isn't another cause of the slowdown. On my system, the cycles range by ~20k typically, not by ~500k cycles, so your expectation should be met.

[sdl]
fullscreen=false
fulldouble=false
fullresolution=desktop
windowresolution=original
output=openglnb
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-CVS.map
usescancodes=true

[dosbox]
language=
machine=svga_s3
vmemsize=4
captures=capture
memsize=63

[render]
frameskip=0
aspect=false
scaler=none

[cpu]
core=dynamic
cputype=pentium
cycles=max
cycleup=10
cycledown=20

[pci]
voodoo=false

[mixer]
nosound=false
rate=44100
blocksize=1024
prebuffer=20

[midi]
mpu401=intelligent
mididevice=default
midiconfig=

[sblaster]
sbtype=sb16
sbbase=220
irq=7
dma=1
hdma=5
sbmixer=true
oplmode=auto
oplemu=default
oplrate=44100

[gus]
gus=false
gusrate=44100
…Show last 59 lines
gusbase=240
gusirq=5
gusdma=3
ultradir=C:\ULTRASND

[speaker]
pcspeaker=false
pcrate=44100
tandy=auto
tandyrate=44100
disney=true

[joystick]
joysticktype=none
timed=true
autofire=false
swap34=false
buttonwrap=false

[serial]
serial1=disabled
serial2=disabled
serial3=disabled
serial4=disabled

[dos]
xms=false
ems=false
umb=false
keyboardlayout=auto

[ipx]
ipx=false

[ne2000]
ne2000=false
nicbase=300
nicirq=3
macaddr=AC:DE:48:88:99:AA
realnic=list

[ide, primary]
enable=false

[ide, secondary]
enable=false

[ide, tertiary]
enable=false

[ide, quaternary]
enable=false

[autoexec]
mount C "."
imgmount D CDMount/game.inst -t iso
c:
cd Blood
BLOOD.EXE
[Screen Setup]
; 
; 
;ScreenMode
; - Chained - 0
; - Vesa 2.0 - 1
; - Screen Buffered - 2
; - Tseng optimized - 3
; - Paradise optimized - 4
; - S3 optimized - 5
; - RedBlue Stereo - 7
; - Crystal Eyes - 6
; 
;ScreenWidth passed to engine
; 
;ScreenHeight passed to engine
; 
; 
ScreenMode = 1
ScreenWidth = 1024
ScreenHeight = 768
; 
; 
Size = 1
Gamma = 2
[Sound Setup]
; 
; 
FXDevice = 0
MusicDevice = 4
FXVolume = 256
MusicVolume = 256
NumVoices = 8
NumChannels = 2
NumBits = 16
MixRate = 16000
MidiPort = 0x330
BlasterAddress = 0x220
BlasterType = 6
BlasterInterrupt = 7
BlasterDma8 = 1
BlasterDma16 = 5
BlasterEmu = 0x620
ReverseStereo = 0

I would also verify the "ExternalFilename" parameter value under [Controls].

If it works, then you may test at higher resolutions by manually editing blood.cfg with another setting such as 1280x1024 (or possible 960V).

Reply 23 of 32, by 2mg

Posted on 
User metadata
Rank Member
Rank
Member

http://imgur.com/a/rzHYC

500k cycles...

Ran directly with dosbox.conf, not using OUWB launcher.

Then I tested it in WinXP SP3 x32 in a virtual machine - same results.

DOSBox Daum is the latest from Ykhwong page dated January 27.2014 - normal dosbox.exe, not _x64 version.

PS: I started using 5xBR shader, and yet, for an extra processing of rendered picture, it causes ZERO difference in performance loss, so unless Shading is done by GPU and not CPU, this gets even more interesting. I really don't understand who's pulling who...

Look, guys, thanks for all your support, 1024x768 with 5xBR shader is a nice experience, very playable with FPS not dropping below 45. We can now go on and on about each setting parameter, and behind it all it might be the latest NVidia driver or something utterly weird buried deep in the system.

Just in case someone gets a new idea please do post it here, I'll check every now and then.

PS:

truth5678 wrote:

On my system, the cycles range by ~20k typically, not by ~500k cycles, so your expectation should be met.

What are your specs?

Reply 24 of 32, by truth_deleted

Posted on 
User metadata

I'm using a slow core2duo system with a relatively old ATI video card.

Your test in running a virtual machine is admirable. That should troubleshoot most problems outside the game itself and possibly the host's video driver. I was wondering if you had any special settings, such as vsync, which are active via the video driver; or running 3rd party software to configure the video driver. I don't strongly believe this is the problem, however. Also, I was testing with Blood 1.0 and noted you had an updated version. It may be worthwhile verifying with an unpatched executable. Did you verify the "ExternalFilename" as mentioned above, since you are running a BMOUSE executable for some reason? I assume so since you tested thoroughly.

I have been planning on testing the game further and verifying the FPS at different cycle levels.

At least you gained new knowledge of Ykhwong's build and its many functions. I believe the xBR shader is all or largely CPU dependent.

It may have been useful to troubleshoot the 3dfx functions in Ykhwong's dosbox build, since it's problems may be related to these problems with VESA. But I do have to test more thoroughly on my system, too.

Edit: I verified FPS drops at 1024x768 resolution with Ykhwong's build, but mainly while the "Show Details" option is chosen. There is a post a while back that mentions the CPU cost of updating that display. Tested this by running with and without the "Show Details" and could subjectively find a difference. I also use a custom build which seems to run full speed at that resolution, but I would have to run FRAPS or similar to verify. Subjectively it is running faster than in the above build. I was mainly testing with this custom build, that is why I missed much of your results and apologize for my partial ignorance of the problem until now. I've previously added bits of code to this custom build, but it would require extensive testing to know the real cause. In summary, your result agrees with Hal's point that higher resolutions are more taxing on the CPU, and not in a linearly related way; in addition, leileilol mentioned the build engine inefficiency at higher resolutions. At 1280x960, even in this custom build, there is slowdown as predicted by them. And as noted earlier, this occurs in real hardware. I may have escaped this constraint at 1024x768, at least partially, by an optimal patch arrangement or by code addition, but any higher resolution will cause slowdowns, presumably on your faster system, too. This is the world of enthusiast builds, and you will be on your own for this pursuit, but you could try building your own dosbox executable and adding some relevant patches. Of course you should try the official 0.74 version first, but I am suspicious that the S3 patch is required to enable the higher resolution modes.

Probably a simple next step is try older builds by Ykhwong. 😀 And try with "Show Details" off.

Reply 25 of 32, by 2mg

Posted on 
User metadata
Rank Member
Rank
Member
truth5678 wrote:

I'm using a slow core2duo system with a relatively old ATI video card.

Told you there is something else besides CPU itself 😀 since you can run it on that rig - not that it sounds impossible or something.

truth5678 wrote:

Your test in running a virtual machine is admirable. That should troubleshoot most problems outside the game itself and possibly the host's video driver. I was wondering if you had any special settings, such as vsync, which are active via the video driver; or running 3rd party software to configure the video driver. I don't strongly believe this is the problem, however. Also, I was testing with Blood 1.0 and noted you had an updated version. It may be worthwhile verifying with an unpatched executable. Did you verify the "ExternalFilename" as mentioned above, since you are running a BMOUSE executable for some reason? I assume so since you tested thoroughly.

I tested in VMWare Workstation 10 with XP SP3 - just copied the same OUWB folder (containts Daum's box) there and ran with mine and yours configs. I'd try on Win98SE, but VMs provide no-to-poor acceleration behavior for anything below XP, didn't want to even bother. My GPU driver is basically vanilla, nothing is enforced like AA or something. BMOUSE is for mouse support, it's used in Build Engine games for a better mouse behavior. I actually even got the latest 0.6. I did try without it of course, it's not the culprit. And nothing against you, but what's the point of playing an un-patched old DOS game if you get me? But hey, if that the source of problems, I'll live with it as a punishment 😉

truth5678 wrote:

I have been planning on testing the game further and verifying the FPS at different cycle levels.

Mine is around 500k almost everywhere, and 900k in "staring at the walls/in a smaller rooms" situations. But, I have to repeat - there is something weird when you have a semi-transparent thing right in front of you - trees on earlier levels cause huge stuttering, as well as glass windows on the train level for some reason. Just a reminder for that thing, might be important for some more DOSBox tech savvy
(Z buffering/vectors/dimension something stuff?).

truth5678 wrote:

At least you gained new knowledge of Ykhwong's build and its many functions. I believe the xBR shader is all or largely CPU dependent.

It may have been useful to troubleshoot the 3dfx functions in Ykhwong's dosbox build, since it's problems may be related to these problems with VESA. But I do have to test more thoroughly on my system, too.

I really don't believe 3Dfx will go above 800x600, it's an alpha released 90's executable in an emulator running a wrapper. xBR is great btw, exactly a touch of unsharpening I wanted.

truth5678 wrote:

Edit: I verified FPS drops at 1024x768 resolution with Ykhwong's build, but mainly while the "Show Details" option is chosen. There is a post a while back that mentions the CPU cost of updating that display. Tested this by running with and without the "Show Details" and could subjectively find a difference. I also use a custom build which seems to run full speed at that resolution, but I would have to run FRAPS or similar to verify. Subjectively it is running faster than in the above build. I was mainly testing with this custom build, that is why I missed much of your results and apologize for my partial ignorance of the problem until now. I've previously added bits of code to this custom build, but it would require extensive testing to know the real cause. In summary, your result agrees with Hal's point that higher resolutions are more taxing on the CPU, and not in a linearly related way; in addition, leileilol mentioned the build engine inefficiency at higher resolutions. At 1280x960, even in this custom build, there is slowdown as predicted by them. And as noted earlier, this occurs in real hardware. I may have escaped this constraint at 1024x768, at least partially, by an optimal patch arrangement or by code addition, but any higher resolution will cause slowdowns, presumably on your faster system, too. This is the world of enthusiast builds, and you will be on your own for this pursuit, but you could try building your own dosbox executable and adding some relevant patches. Of course you should try the official 0.74 version first, but I am suspicious that the S3 patch is required to enable the higher resolution modes (at least from SVN builds as configured).

It's off by default when I run it, I don't even see the option to make "Show Details" on by default. Frankly, 800x600 works basically without ever going below 50 FPS, and 1024x768, which I am now playing with for the last 2 days, is close. It's probably the game/engine/emulation all together somehow mixed to not be able to push above those rez's without actually breaking themselves in the process, just like that weird transparent texture behavior. Another example is when I use a shotty up close on a zombie, that blood spurt causes a quarter of a second of stutter. Or simply, take 1024 or one step above. On 1st level go to the mortuary courtyard. Press Escape, the menu has those blood drips. Notice the slowdown.

But as I said, I am now content with 1024x768 with 5xBR. It's not that much a difference (graphically) running it in 1600x1200, it's still a Build Engine 1997 DOS game, it won't look like Tomb Raider or Quake no matter what... What's annoying me is the shooting in Build engine, Doom for example had mostly avoidable projectiles, while Blood is hit/miss, it's really weird sometimes...Anyway, if you really want to chase the devil, go ahead, I'm here listening 😉

Reply 26 of 32, by 2mg

Posted on 
User metadata
Rank Member
Rank
Member

Oh boy here we go:

This happens, only on this section, randomly.

http://speedy.sh/4Nh3f/DosBox-2014-03-26-05-14-26-864.avi

*These explosions are NOT something I saw for the first time, so I can't say it's them, as they do seem like they are causing real havoc.

**Please notice that the game itself is running "behind" the lagging picture normally, shots are immediately fired when I click, etc., just the picture lags horribly - CONFIRMED, at the end of the corridor the fireballs stop. When I go down some mice are there and then it starts...

Reply 27 of 32, by truth_deleted

Posted on 
User metadata

I think you resolved the issue fairly well for now. I have now found slowdowns, too, at 1024x768; it seems consistent with your results on the faster machine. I haven't yet been able to reproduce some of the other issues fully, especially the high range of cycles (20k versus 500k) used throughout the game.

I wasn't able to download the above video file, unfortunately.

Also, here is a site to run the game in the host OS (says XP but another ran it in W7), but I haven't tested it yet: http://forums.transfusion-game.com/viewtopic.php?t=1074

Reply 28 of 32, by 2mg

Posted on 
User metadata
Rank Member
Rank
Member
truth5678 wrote:

I think you resolved the issue fairly well for now. I have now found slowdowns, too, at 1024x768; it seems consistent with your results on the faster machine. I haven't yet been able to reproduce some of the other issues fully, especially the high range of cycles (20k versus 500k) used throughout the game.

I wasn't able to download the above video file, unfortunately.

Also, here is a site to run the game in the host OS (says XP but another ran it in W7), but I haven't tested it yet: http://forums.transfusion-game.com/viewtopic.php?t=1074

That's some configuring there... I'll try it later.

Also, to download just click at the very top where the filename in large font is written, it's next to DOWNLOAD which has stars under it.

Reply 29 of 32, by truth_deleted

Posted on 
User metadata

I viewed the video and tested further on my configuration. The FPS will change drastically in any resolution mode (tested with 640H and above). This may be the way the build engine updates the display and/or the dosbox video emulation; however, even though the FPS drops as low as 0 while at or near a standstill, there is not necessarily any noticeable slowdown. I don't consider this an issue since it doesn't disrupt gameplay.

At max cycles the cycles range around 250k, regardless of the resolution (640H and higher). However, at higher resolutions the median FPS is lower and the slowdown is noticeable. The continuous FPS reading does not seem to be a reliable indicator of game speed/playability.

I don't find the the large fluctuations in cycles, but my system is slower than the one you use for testing. Perhaps the high cycle count reveals a bug in the build engine at the higher VESA modes. If this was the case, I don't have a fast enough system to test.

Some of the symptoms you describe above, in addition to clipping bugs, have been reported in real hardware (via google search of newsgroups and similar sites). If this was a VESA specific problem, then Quake 1 would provide a test example to observe similar slowdowns; assuming that your latest issue above has not been reproduced at lower resolutions. If so, then the build engine becomes the likely cause. In this case, perhaps the 3dfx build could be tested for a similar result; especially the texture-based slowdown.

The build engine is apparently not as efficient in rendering graphics as a modern game is; also, at high resolution the video emulation becomes very taxing on the cpu. 😀

Reply 30 of 32, by 2mg

Posted on 
User metadata
Rank Member
Rank
Member
truth5678 wrote:

I viewed the video and tested further on my configuration. The FPS will change drastically in any resolution mode (tested with 640H and above). This may be the way the build engine updates the display and/or the dosbox video emulation; however, even though the FPS drops as low as 0 while at or near a standstill, there is not necessarily any noticeable slowdown. I don't consider this an issue since it doesn't disrupt gameplay.

Uhm... it seems that video was my doing - I use ctrl to crouch, and then 1 to switch to first weapon, and ctrl+1 switches Cores in DOSBox, so I believe that one was my doing, I am sorry... I really didn't know ctrl+1 to 4 switches cores, especially wouldn't expect that to work when in fullscreen.

truth5678 wrote:
At max cycles the cycles range around 250k, regardless of the resolution (640H and higher). However, at higher resolutions the […]
Show full quote

At max cycles the cycles range around 250k, regardless of the resolution (640H and higher). However, at higher resolutions the median FPS is lower and the slowdown is noticeable. The continuous FPS reading does not seem to be a reliable indicator of game speed/playability.

I don't find the the large fluctuations in cycles, but my system is slower than the one you use for testing. Perhaps the high cycle count reveals a bug in the build engine at the higher VESA modes. If this was the case, I don't have a fast enough system to test.

Some of the symptoms you describe above, in addition to clipping bugs, have been reported in real hardware (via google search of newsgroups and similar sites). If this was a VESA specific problem, then Quake 1 would provide a test example to observe similar slowdowns; assuming that your latest issue above has not been reproduced at lower resolutions. If so, then the build engine becomes the likely cause. In this case, perhaps the 3dfx build could be tested for a similar result; especially the texture-based slowdown.

The build engine is apparently not as efficient in rendering graphics as a modern game is; also, at high resolution the video emulation becomes very taxing on the cpu. 😀

Anyway, I believe all this mess about cycles is now sorted out thanks to your support 😀

Go to top of page Go to top of page
Back to DOSBox Games/Apps
Close window
Close window