800x600=480000
1280x1024=1310720

2,7 times as many pixels that need to be calculated and shown.

h-a-l-9000 wrote:

800x600=480000
1280x1024=1310720

2,7 times as many pixels that need to be calculated and shown.

Here's the deal: I've managed to find out that the game runs around 500k cycles, core and cpu is on Auto.

According to Wiki, using too many cycles will result in sound stuttering and game slowdown, which happened to me, EXCEPT it's using only 25% of my CPU (Quad i5 3.6GHz) when I push to 1000k cycles, so instead of gaining lost FPS by using more of my CPU with higher cycles, performance drops and the CPU usage doesn't increase.

What else I noticed is that when I look up-close through things like fences or bushes, FPS drops drastically for some reason too.

I can't figure out why this is happening, I even disabled sound completely for testing.

PS: Cycles jump up when I'm staring at a wall or my feet and the DOSBox's Window Title says Dynamic ~900k Cycles BLOOD 99.1%, when traveling or in combat it drops into half cycles and BLOOD 55%.

That game is available for sale here: http://www.gog.com/game/one_unit_whole_blood. It provides support for non-technical users and those unable to configure dosbox.

Also, it is not a dosbox bug that higher resolutions use an ever growing number of pixels, it can be solved with arithmetic as Hal showed above.

Use one of the Daum builds (i.e. with the settings menus). Set CPU to "Maximum Cycles", and turn on "Show Details" under Main.

The number shown prior to the FPS is the number of CPU cycles you can emulate. If you want to set a specific number of cycles to emulate it needs to be below that number or you will get slowdowns due to emulating more cycles than you can in realtime. Once you know the max you can emulate and use that or just leave things set on max, you can then see what resolution you'll be able to deal with.

Even with a high-end system very high resolutions in build engine games can be strenuous.

Also, btw, it's only using 25% of your CPU because DOSBox's CPU emulation is not multi-threaded. So it's using 100% of one of you're CPUs cores. There are a few tasks that are offloaded to other cores, but they tend to not use much CPU.

Build a Pentium IV 2GHz DOS system if you wish to play Blood smoothly at 1280x1024. Yes, it demands *that* much CPU. This is not a peculiar problem.

truth5678 wrote:

That game is available for sale here: http://www.gog.com/game/one_unit_whole_blood. It provides support for non-technical users and those unable to configure dosbox.

Also, it is not a dosbox bug that higher resolutions use an ever growing number of pixels, it can be solved with arithmetic as Hal showed above.

It's not just upping the resolution that causes the slowdown, please see my previous post, especially the underlined part.

kolano wrote:

Use one of the Daum builds (i.e. with the settings menus). Set CPU to "Maximum Cycles", and turn on "Show Details" under Main. […]
Show full quote

Use one of the Daum builds (i.e. with the settings menus). Set CPU to "Maximum Cycles", and turn on "Show Details" under Main.

The number shown prior to the FPS is the number of CPU cycles you can emulate. If you want to set a specific number of cycles to emulate it needs to be below that number or you will get slowdowns due to emulating more cycles than you can in realtime. Once you know the max you can emulate and use that or just leave things set on max, you can then see what resolution you'll be able to deal with.

Even with a high-end system very high resolutions in build engine games can be strenuous.

Also, btw, it's only using 25% of your CPU because DOSBox's CPU emulation is not multi-threaded. So it's using 100% of one of you're CPUs cores. There are a few tasks that are offloaded to other cores, but they tend to not use much CPU.

I actually am, I wanted to put a shader to smooth things out a bit, but they are either too harsh (oily picture) or unnoticeable. It's also configured thoroughly and properly, I've spent a whole day testing DOSBox's capatibilites 😉

And about Cycles - that's the thing:

"CPU = Dynamic 600k = 100%, 27 FPS -0 BLOOD 99.6%" and then it changes into 900k = 100% when there aren't many things to draw. So what's my max? Because I do know that if I manually set close to 1000k sound's stuttering and game slows down. Why is the left cycle count dropping??? Also, not even one core is maxed out, just a spike up to 90ish % now and then... Staring at the wall while standing gives 900k cycles and 7-20FPS. Staring at the wall and moving gives 800k cycle and 60FPS. Looking around and moving gives 600k and 27FPS.

leileilol wrote:

Build a Pentium IV 2GHz DOS system if you wish to play Blood smoothly at 1280x1024. Yes, it demands *that* much CPU. This is not a peculiar problem.

For a 1997 Build Engine game, even at that resolution, that seems too much, but you seem to know more than me, I'm not arguing. However, a i5 @ 3.6GHz should be able to emulate that resolution. However, the problem seems to be something weird, see what I've outlined in my last post - my CPU is at 25% utilization, there is a spike up to 90% in 1-2 cores now and then, but mostly it's in 25% range.

PS: Tried all Core settings on Auto CPU setting - on Auto/Dynamic Max setting, cycles wave up and down depending on the scenery for some reason, between 600 and 900k cycles, yet on any other Core setting (even if manually set cycles) the game SOUND stutters on only <30k, is normal on 50k, and again slows on 60k> - the game itself is unplayable on any setting other than Auto/Dynamic...

You haven't configured the cycles setting properly. Also, I verified that the arithmetic result by Hal is correct, and therefore it is not a dosbox bug as asserted again by the OP.

2mg wrote:

For a 1997 Build Engine game, even at that resolution, that seems too much, but you seem to know more than me, I'm not arguing.

There's many cases of 90's games futureproofed for support unrealistically beyond the high-end PCs of their release years. Jane's US Navy Fighters, released in 1994, has trouble playing smoothly on Pentium IIIs in SVGA with the texturing enabled, for example. Build engine's VESA 2.0 support added in 1995 during its development opened the door to support 1600x1200 even though the machines of the era can barely straddle along 640x480, etc.

truth5678 wrote:

You haven't configured the cycles setting properly. Also, I verified that the arithmetic result by Hal is correct, and therefore it is not a dosbox bug as asserted again by the OP.

I apologize that I thought this is a bug. But I've tried every possible cycles setting, you can see above your post about what's going on. In short, game only works on Auto or Dynamic Core with upper cycle limit being 1000k cycles, which btw doesn't even consume a whole CPU core, but cycles drop when there is heavier graphical load to draw. I'd record it, but game starts stuttering when I try that, sorry.

leileilol wrote:

2mg wrote:

For a 1997 Build Engine game, even at that resolution, that seems too much, but you seem to know more than me, I'm not arguing.

There's many cases of 90's games futureproofed for support unrealistically beyond the high-end PCs of their release years. Jane's US Navy Fighters, released in 1994, has trouble playing smoothly on Pentium IIIs in SVGA with the texturing enabled, for example.

One of the reasons Carmack started the 2.5D revolution, something along those lines...

http://www.dosbox.com/wiki/GAMES:Blood
http://www.dosbox.com/comp_list.php?showID=679&letter=B

Those two links provide dosbox configurations for running Blood. For comparison, did you try a plain version of dosbox, 0.74 and SVN, instead of the Daum build? Are you running the 3dfx binary for the game?

Is your goal to run at the highest resolution possible? It may be worthwhile to try the 3dfx binary at the very high resolutions. Otherwise, I recommend running in software mode at 640x480 and then integer doubling the screen resolution to 1280x960 via output=openglnb (assuming the monitor screen size is ideal for this setting). For some smoothing, then output=opengl is an option. For high quality smoothing, I've used output=openglhq (in Ykhwong's build).

It is absurd that the higher resolutions in software mode require 1 million cycles. It is presumably due to the Build engine inefficiencies at those resolutions, as stated above. If curious, you may verify this by running Quake 1 and Duke Nukem 3d and record their FPS at different resolutions and among different in-game environments, such as "staring at floor" versus a lot of action on screen.

If you would like graphical smoothing by the game itself, then it would be worthwhile to run the 3dfx binary of the game: http://dukertcm.com/knowledge-base/downloads- … cm/blood-patchs. This will work in Ykhwong's build which has the 3dfx patch by kekko/gulikoza or else in glide mode (another gulikoza patch; using openglide or nglide as the glide wrapper). I believe that glide mode, assuming you are using windows or linux as the host to run dosbox, will run fast at all resolutions.

I haven't mentioned 3dfx scaling, which is yet another option. But the above should keep you busy for a while. 😀

truth5678 wrote:

http://www.dosbox.com/wiki/GAMES:Blood http://www.dosbox.com/comp_list.php?showID=679&letter=B […]
Show full quote

http://www.dosbox.com/wiki/GAMES:Blood
http://www.dosbox.com/comp_list.php?showID=679&letter=B

Those two links provide dosbox configurations for running Blood. For comparison, did you try a plain version of dosbox, 0.74 and SVN, instead of the Daum build? Are you running the 3dfx binary for the game?

Is your goal to run at the highest resolution possible? It may be worthwhile to try the 3dfx binary at the very high resolutions. Otherwise, I recommend running in software mode at 640x480 and then integer doubling the screen resolution to 1280x960 via output=openglnb (assuming the monitor screen size is ideal for this setting).

Yes, tried it with GOG's 0.73.
Updated to 0.74.
Now using latest Daum and OUWB Launcher.
I'm running it in Direct3D now (tried OGL, Surface and Overlay with no FPS difference).
Fullscreen resolution is Desktop (1920x1080) but in-game is now 1024x768 (above was too slow), with Aspect Correction and Double Buffering (tried without both, no deal) and NO extra scaler.

Now here's the catch:
Option 1 - use maximum VESA mode 800x600 which doesn't cause FPS drops, and set Fullscreen Resolution = Desktop (+aspect fix obviously).
Option 2 - use maximum VESA mode 800x600 which doesn't cause FPS drops, and set Fullscreen Resolution = Original + 2x Scaler (+aspect)
Option 2a - 800x600, Original plus my video driver/GPU scaling that automatically preserves aspect ratio.

Thing is that none of these options provide a clarity that an original in-game resolution above VESA, such as 1024x768+ provides. They are both three different means to get the same result - upscale low(ish) game resolution, and that's why I aimed above 800x600 😀

Daum has 3 OpenGLs - normal, No Bilinear and High Quality, so to me it seems just about how stretching will work, but I'll give it a try with 800x600 stretched with Fullscreen=Desktop, I presume that's their point - having a "scaling stype" in themselves.

And I'll try 3DFX, haven't even thought about that one.

After further thought, as I can't test it, I think the 3dfx binary will limit the physical resolution to 800x600, whether in Glide or the internal 3dfx emulation modes. However, there is a 3dfx scaling technique which would scale to your monitor size and may produce good results; documentation here for the 3dfx settings: http://www.si-gamer.net/truth/. Binary here: http://www.si-gamer.net/truth/dosbox-3dfx.zip. I would try 800x600 in 3dfx mode and use 3dfx scaling at an integer level of 2 in a window, then try stretching full screen via the special dosbox.conf setting. This is an advanced method. I don't recall whether there are graphical artifacts from this method, so integer scaling may be better than full screen scaling.

However, for the VESA modes, I would try 640x480 and then integer scale by 2, in a window and then full screen with the use of output=openglnb. Experiment with aspect = true and =false for speed differences. Then, try 800x600 at full screen and compare the visual quality to the above. If you would like graphical smoothing, then change to output=opengl.

After trying the above, then try Blood's software mode with output=openglhq, while setting the dosbox "window" to full screen. This would require Ykhwong's build. It will provide high quality smoothing without a performance penalty. This will work with an in-game resolution of 640x480, but it may provide unexpectedly good results at 800x600.

In Quake 1, it doesn't run fast at high resolution VESA modes either, such as at 1024x768, but the above methods should produce comparable results. I suspect the 3dfx scaling method would be equivalent and subjectively better, given the desirability of 3dfx smoothing. Next, the "openglnb" method should produce an image of somewhat lesser quality, but I would guess (much) better than GPU scaling. I also find this scaling method to work well in many instances, and so it would be preferable over no scaling.

When testing the above, use core=dynamic, cpu=auto, and cycles=max. It is not necessary to change this configuration given the game works with these settings. For testing 3dfx modes, the output must be opengl and Ykhwong's build has documentation on how to set the glide parameters in dosbox.conf.

truth5678 wrote:

After further thought, as I can't test it, I think the 3dfx binary will limit the physical resolution to 800x600, whether in Gli […]
Show full quote

After further thought, as I can't test it, I think the 3dfx binary will limit the physical resolution to 800x600, whether in Glide or the internal 3dfx emulation modes. However, there is a 3dfx scaling technique which would scale to your monitor size and may produce good results; documentation here for the 3dfx settings: http://www.si-gamer.net/truth/. Binary here: http://www.si-gamer.net/truth/dosbox-3dfx.zip. I would try 800x600 in 3dfx mode and use 3dfx scaling at an integer level of 2 in a window, then try stretching full screen via the special dosbox.conf setting. This is an advanced method. I don't recall whether there are graphical artifacts from this method, so integer scaling may be better than full screen scaling.

However, for the VESA modes, I would try 640x480 and then integer scale by 2, in a window and then full screen with the use of output=openglnb. Experiment with aspect = true and =false for speed differences. Then, try 800x600 at full screen and compare the visual quality to the above. If you would like graphical smoothing, then change to output=opengl.

After trying the above, then try Blood's software mode with output=openglhq, while setting the dosbox "window" to full screen. This would require Ykhwong's build. It will provide high quality smoothing without a performance penalty. This will work with an in-game resolution of 640x480, but it may provide unexpectedly good results at 800x600.

In Quake 1, it doesn't run fast at high resolution VESA modes either, such as at 1024x768, but the above methods should produce comparable results. I suspect the 3dfx scaling method would be equivalent and subjectively better, given the desirability of 3dfx smoothing. Next, the "openglnb" method should produce an image of somewhat lesser quality, but I would guess (much) better than GPU scaling. I also find this scaling method to work well in many instances, and so it would be preferable over no scaling.

When testing the above, use core=dynamic, cpu=auto, and cycles=max. It is not necessary to change this configuration given the game works with these settings. For testing 3dfx modes, the output must be opengl and Ykhwong's build has documentation on how to set the glide parameters in dosbox.conf.

Here's the deal.

Blood 3Dfx was released as ALPHA. That says a lot.

That aside, I had two options to try - internal emulation and a couple external wrappers.

Internal emulation works ONLY as software mode, which is god dam*ed slow and ugly. I've read thru Daum manual, and setting Voodoo and Output to OpenGL should provide hardware acceleration, however, I just get a couple of colored boxes in the top right side of the screen. So this one is out.

External wrapper provided with Daum doesn't work, at least for me, seems I need to set the resolution somewhere but I can't find any documentation how to edit OpenGlide wrapper's settings Daum included.

nGlide on the other hand provides 640x480 MAX, so that's useless, since I'm looking for a native increase in resolution, at least 800x600.

***These guys managed to get it up and running on 800x600: http://forums.transfusion-game.com/viewtopic.php?t=1509
However - "3DFX.EXE was released in it's alpha stage. It does not support voxels, it evokes visual glitches, and suffers from memory leaks."
Plus, it avoids DOSBox per se, and it needs (call me lazy) way too much work for something that may or may not work, plus it needs extra audio drivers, I don't know if it's scaling to 800x600 or is it native, it looks way too blurry even though I did want a slight "desharpen" effect, etc.

Shorty version - 3dfx version is almost broken.

I'll satisfy myself with 800x600 or 1024x764 upscaled to Desktop setting, however my question still stands - why does the number of cycles drop when there is intensified action/terrain on screen? I understand FPS drops when not enough cycles, however why are there Cycle drops in the first place?

And I'll give dgVoodoo a try, since Glidos has that logo, and dgVoodoo is still maintained.

dgVoodoo2 worked nicely for me with unforced res (800x600 ingame) and msaa, even on a low-end video card.
Forced res or antialiasing causes messed up rendering because the game renders very thin, 1 pixel Wide vertical triangles (It comes from the raytracer of the Build engine).

However there is an inconvenience with the 3dfx Alpha: It contains memory leaks, so the game periodically quits during play, you have to save quite often.
I think managing texture memory is completely missing from the Alpha, so When It finishes eating up all available memory, then it Just quits as if It crashed.

Dege wrote:

dgVoodoo2 worked nicely for me with unforced res (800x600 ingame) and msaa, even on a low-end video card. Forced res or antialia […]
Show full quote

dgVoodoo2 worked nicely for me with unforced res (800x600 ingame) and msaa, even on a low-end video card.
Forced res or antialiasing causes messed up rendering because the game renders very thin, 1 pixel Wide vertical triangles (It comes from the raytracer of the Build engine).

However there is an inconvenience with the 3dfx Alpha: It contains memory leaks, so the game periodically quits during play, you have to save quite often.
I think managing texture memory is completely missing from the Alpha, so When It finishes eating up all available memory, then it Just quits as if It crashed.

And I'm back with similar results.

Glidos - huge logo, gotta buy it or skip it, however same rule applies, see below, so it's useless, except I didn't test for longer gameplay stability, maybe that's a hidden plus.

Internal emulation - voodoo=auto/opengl output=opengl is a no no. voodoo=auto output=*any other* works at around 20 FPS, same rule applies.

External emu with dgVoodoo - works with solid speeds, BUT since this whole thread is about my unstable cycles/FPS, I don't know whether dgVoodoo can't hold stable FPS, or is it only me and my PC/DOSBox/3DFx Alpha Blood version. Same rule.

nGlide - something about something, I forgot, perhaps I didn't set 512x441(?)/640x480/800x600 before testing, didn't work

THE RULE(s):
- lower gamma to minimum before starting,
- set the resolution before starting
- 640x480 and 800x600 resolutions work
- everything can (and will, since you don't want a 10x10 centimeters picture on your 24' screen) be scaled to your screen -> read "blurring"
- going above 800x600 (I tested only 1024x768) works but half the textures are having a baaaad acid trip -> and this is Blood, you are playing this game because it's bad for your mental health. So, that's how much them textures be trippin' colors.
*I didn't use dgVoodoo like in the link from Transfusion forums I posted earlier, just set it up and started it like with nGlide*
**I tried using Glidos' 3dfx.exe, as I thought it was a fixed version**

Conclusion:
- 3Dfx Blood is worthless since game can be played at 800x600 max, and is known to cause problems and requires additional setup.

I reiterate my question, the one why I started this thread, with another approach:
- When there is very little graphical material to draw, such as a flat wall, max. cycles can be upped to 1000K, and the DOSBox measures current cycles around that value, ie. 998001 and FPS is high.
- When there is a lot of graphical material OR standing in front of a semi-transparent textures such as fences/bushes for some reason, cycles drop to 500-600K, but because max is 1000k, audio stuttering and slowdown happens. Then, lowering max cycles to 500k removes the difference between max possible and actual cycles, BUT 500k is not enough cycles to provide a stable high FPS. None of this is caused by CPU overload.
- What gives?

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

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'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).

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. 😀

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.

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".

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.

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.