Since ykhwong seems not being updated anymore and have some strange issues, which other custom builds are being kept up-to-date and have some of those features that plain svn does not?
wrote:Since ykhwong seems not being updated anymore and have some strange issues, which other custom builds are being kept up-to-date and have some of those features that plain svn does not?
My build (see my signature) contains some of the features the fellow members here added as well.
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
wrote:wrote:Since ykhwong seems not being updated anymore and have some strange issues, which other custom builds are being kept up-to-date and have some of those features that plain svn does not?
My build (see my signature) contains some of the features the fellow members here added as well.
Your build works great. I miss a few features, though, which make heavier games run smoother, like vídeo memory size, ram above 63mb and Pentium_mmx cpu. I also wonder what makes any build to hiccup when running them after the computer has been running for hours (a restart always fixes it). Running Win7 32 bits. This never happened on WinXP using the same builds.
wrote:Since ykhwong seems not being updated anymore and have some strange issues, which other custom builds are being kept up-to-date and have some of those features that plain svn does not?
I found ykhwong (daum)'s build to be overkill and crash-happy for what I wanted
This is my current build, minus ffmpeg: Re: 3dfx voodoo chip emulation is back!
It is geared around trying to capture high-quality footage, so I'd just as soon disable the advanced scalers, but haven't.
My build is based on SVN-r4000 with the SDL2 patch. It's different from Yesterplay80's build (previous post) in that it doesn't have Ant_222's pixel perfect patch, and doesn't have the normal4x/5x/6x patch. I also don't have SDL_Sound built into mine, so there's no ogg/mp3/flac/etc support for cd-audio. I have MUNT and Fluidsynth compiled into mine, but they're static (no dll's.)
I'll note that I've only used the Tomb Raider 3DFX demo to test the glide patch, and don't actually own any DOS-era games that use a 3Dfx card, so I can't confirm any functionality regarding Voodoo support. It doesn't crash for me.
My present build has ffmpeg support (from the dosbox-x fork) and a AVI-cut change to the avi recording so that it stops and starts a new video every X bytes, which is basically because the original AVI recorder hits 4GB and then the video becomes unusable, and is unusable if dosbox crashes. The avi-writer from dosbox solves the latter, but only allows for 2GB and then it just stops writing entirely. I'm not happy with the ffmpeg support in dosbox-x, as it uses a depreciated api and seems confused. What you really want is ffmpeg to be set to -qp 0, but the dosbox-x ffmpeg patch just sets it to 25mbits. You don't want lossy video at 320x200, as AVC operates on 4x4 or 8x8 blocks, the same as some text fonts.
Generally builds should have some goal in mind. The base SVN build's only goal is emulating a 386/486 DOS environment.
- The Daum build doesn't really have any goal other than "add everything possible", as it incorporates conflicting patches, and some games doesn't work without turning off half the features enabled. It's the build people generally use for getting Win95 to work
- The EmuCR build, when it doesn't contain malware, is less capable than the stock 0.74 build so it's just a SVN build without SDL_Sound.
- VDosPlus build moves in the direction of getting DOS applications (eg Wordperfect), not games to work, so things like long file names and copy-paste support is in it.
- doxbox-X is based on ykhwong's Daum codebase as far as the SVN is concerned. It's goal is more accurate hardware emulation (eg uses a BIOS to boot, and such)
It should be stated that Win95 should not be a goal with DOSBOX. Voodoo support in DOSBOX patches is only really meant to support DOS games that first generation 3DFX hardware has support for, not Windows games. But given the right patches, this is the only current way to get 3D acceleration in Windows95 under DOSBOX.
Demo-scene requires emulating hardware more accurately, and the source code is rarely available for demos. So emulating bugs in some hardware is required. So a build for games (which tend to not utilize bugs in hardware) may have higher accuracy in video and audio emulation than the actual hardware it was designed for. A build for demo-scene demos may have to be tuned exactly to the demo's expected hardware.
Like I was looking at the differences between the SoundBlaster code in Dosbox-x and SVN and dosbox-x appears to have added support for the SB16-ASP, but I'm not aware of any game that uses it.
When I record games, I pick the MT-32 or Fluidsynth, depending on if the game was designed for MT-32 or General Midi, because that is the only way you can record the output in sync with the video. If my goal was simply to play the game, then using the SB X-Fi's soundfont support is more readily available. Under Windows 10, it's no longer any "midi mapper" so even if you have a hardware Midi device, you have no control over what Windows uses. That's my justification for those two patches.
Nuked and more accurate gameblaster, more accurate tandy/pcjr, etc are similarly in line with trying to get pre-soundcard games to sound like they are supposed to, but it requires a lot of back and forth.
Thanks for the links. dosbox-X performs much like Daum, with problems on the same games (UW1, UW2 and CGII, mostly). I wonder what is causing hiccups on Win-7 32 bits on every single build.
wrote:I wonder what is causing hiccups on Win-7 32 bits on every single build.
I never encountered any "hiccups" in neither the vanilla SVN build, nor any other version of DOSBox I used so far. Does that happen with other games, too, or does it really only occur in DOSBox? With which game, for example?
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
wrote:wrote:I wonder what is causing hiccups on Win-7 32 bits on every single build.
I never encountered any "hiccups" in neither the vanilla SVN build, nor any other version of DOSBox I used so far. Does that happen with other games, too, or does it really only occur in DOSBox? With which game, for example?
I only notice hiccups when I push Dosbox out of spec, eg 96000khz, capture turned on, mt-32/fluidsynth turned on with small buffers. If you set the audio buffer higher (96khz requires 2048, 48khz requires 1024) then you induce more lag, but the emulation is working correct. The explanation for this is that when capture is turned on, it's in the main thread, which means it doubles the underlying host CPU requirements. Even when all this is turned on, it's not hitting 100% on the CPU. MT-32 and Fluidsynth are in their own threads, so they don't really have a great impact on the main thread.
The largest impact outside of the CPU cycles itself is capturing audio. A CD is 44.1khz stereo, and requires 150KB/sec, double the frequency and it becomes 300KB. Peanuts. The Video capture on the other hand has a zlib process and an xor process, and doesn't scale. So if you capture a 320x200 game, it will rarely stutter, but if you capture Windows 95, it might have more opportunity to stutter.
Here's an example.
This is a capture of the Windows 95 Easter-egg, in Dosbox with FluidSynth compiled into it.
https://youtu.be/gDLjZHPEjo4
When I captured it, there was definitely a few stutters, but if you sit through the whole thing, you don't hear any.
wrote:I only notice hiccups when I push Dosbox out of spec, eg 96000khz, capture turned on, mt-32/fluidsynth turned on with small buff […]
wrote:wrote:I wonder what is causing hiccups on Win-7 32 bits on every single build.
I never encountered any "hiccups" in neither the vanilla SVN build, nor any other version of DOSBox I used so far. Does that happen with other games, too, or does it really only occur in DOSBox? With which game, for example?
I only notice hiccups when I push Dosbox out of spec, eg 96000khz, capture turned on, mt-32/fluidsynth turned on with small buffers. If you set the audio buffer higher (96khz requires 2048, 48khz requires 1024) then you induce more lag, but the emulation is working correct. The explanation for this is that when capture is turned on, it's in the main thread, which means it doubles the underlying host CPU requirements. Even when all this is turned on, it's not hitting 100% on the CPU. MT-32 and Fluidsynth are in their own threads, so they don't really have a great impact on the main thread.
The largest impact outside of the CPU cycles itself is capturing audio. A CD is 44.1khz stereo, and requires 150KB/sec, double the frequency and it becomes 300KB. Peanuts. The Video capture on the other hand has a zlib process and an xor process, and doesn't scale. So if you capture a 320x200 game, it will rarely stutter, but if you capture Windows 95, it might have more opportunity to stutter.
Here's an example.
This is a capture of the Windows 95 Easter-egg, in Dosbox with FluidSynth compiled into it.
https://youtu.be/gDLjZHPEjo4When I captured it, there was definitely a few stutters, but if you sit through the whole thing, you don't hear any.
It seems like this is the same issue: (Sound?) stutters if not using fixed cycles? and it doesn't seem to happen for me after a fresh OS reboot.
wrote:wrote:I wonder what is causing hiccups on Win-7 32 bits on every single build.
I never encountered any "hiccups" in neither the vanilla SVN build, nor any other version of DOSBox I used so far. Does that happen with other games, too, ior does it really only occur in DOSBox? With which game, for example?
I can notice the stuttering right on the blinking cursor before running any game.
Ok, stuttering seems to be gone with max cycles if you specify a cycle limit. Is there any updated build with extra features (video memory support, memory=512, 3dfx, sb16vibra, Pentium_mmx, etc.) without the X code?
