VOGONS

Common searches


First post, by Gemini000

User metadata
Rank l33t
Rank
l33t

OK, so I've been running DOSBox on my Win8 system for a little over a month now. For the most part, I haven't run into too many issues, save for DDraw mode not working nicely due to Microsoft depreciating the heck out of it, so I've had to swtich over to OpenGL and avoid using any graphics shaders that require DDraw. :P

However, recently when I was trying out games using the "max" cycles setting, I ran into what I thought were very strange framerate issues where it seemed to constantly fluctuate between high framerates and lower framerates. This was only happening with games I hadn't yet played so I didn't think anything of it and just set fixed cycles counts to get around it.

However, upon playing some games I had working perfectly fine with max cycles on my old WinXP system, I discovered the same problems, and after testing some things out I realized this wasn't actually a framerate problem, the emulation speed itself is fluctuating! o_O;

It kind of oscillates, going faster in some moments and slower in others, and switching between these extremes once or twice per second. What's odd is that this is only a visual problem. IE: The game is still playing at the correct speed and audio is still playing at the correct speed, but each frame seems to be staying on screen longer than it's supposed to and in order to catch up once there's some backlog, a number of frames are drawn and pass faster than they're supposed to. (I don't think it's related to 320x200's 70 Hz compared to LCD monitor 60 Hz considering this also happens with 640x480 resolution games.)

I'm also encountering random game crashes with games that NEVER crash (like OMF2097), thanks to divide overflow errors and I think it's related to this problem.

I should also note that lowering the % emulation speed does not solve this issue. Setting a fixed cycles count does, but is inconvenient for any game that should be working best with max cycles, since you have to swap between low cycles and high cycles depending on what's going on and can play havoc with joystick calibration.

Basic System Specs:
* AMD FX-8350 8-Core CPU @ 4.00 GHz
* GeForce GTX 660 GPU /w 2 GB RAM
* 16GB RAM
* Windows 8 Pro 64-bit

All of my drivers for the BIOS, Windows, GPU, CPU, etc., are up to date. It's also interesting to note that no matter what game I'm playing with max cycles, the CPU core DOSBox is using never hits 100% usage. Not even close. The highest I've seen for a single core with DOSBox with a game set to max cycles is 75%.

I would almost call this a graphics driver problem, if not for the fact that setting a fixed cycles count solves the problem, so I'm leaning towards something else, probably CPU or Win8 related... maybe both since I've been having similar problems with Flash. (Though those problems went away by disabling power saving settings in the BIOS, whereas my DOSBox problems are not affected by those BIOS settings.)

Last edited by Gemini000 on 2013-07-03, 07:24. Edited 2 times in total.

--- Kris Asick (Gemini)
--- Pixelmusement Website: www.pixelships.com
--- Ancient DOS Games Webshow: www.pixelships.com/adg

Reply 2 of 28, by Gemini000

User metadata
Rank l33t
Rank
l33t

*tests*

...no. :O

So maybe it is GPU related? But then still, why does the problem go away with a fixed cycles count?

...I'm gonna test some graphics driver settings. It could be one of the optimizations in there for OpenGL stuff may be messing with the DOSBox side of things and I have a good idea of which ones to try first. (Threaded Optimization is often a good one to start with.)

Back in a little to report my progress.

--- Kris Asick (Gemini)
--- Pixelmusement Website: www.pixelships.com
--- Ancient DOS Games Webshow: www.pixelships.com/adg

Reply 3 of 28, by Shagittarius

User metadata
Rank Oldbie
Rank
Oldbie

Are you running any programs that limit your FPS like EVGA Precision X? I had a problem that seems similar and it was due to capping my framerate in my main OS.

Reply 5 of 28, by Gemini000

User metadata
Rank l33t
Rank
l33t

*was in the middle of writing my response before you suggested that, robertmo*

I traced the problem to the "Vertical Sync" setting in my graphics drivers. If I disable vertical sync, the problem goes away in OpenGL mode.

What's very peculiar about this is that I've had vertical sync forced to "on" since forever, on all of my previous systems. I've very rarely run into trouble doing this. So the fact that it had no effect on DOSBox with older 98 and XP machines using DirectDraw compared to now using OpenGL is unusual and annoying. :|

At least I can set it to be program specific, so that vsync will only be disabled for DOSBox, but still, that's just weird. Might be a good point to make note of in the DOSBox manual/readme. I'm considering doing an overview of DOSBox troubleshooting with my next filler video considering the problems I've run into lately and the workarounds I've had to perform.

BTW: Anyone have any ideas why vertical retrace syncing might be doing this, even with DOS games that run the same framerate as my monitor and why it only affects games running with the "max" cycles setting?

--- Kris Asick (Gemini)
--- Pixelmusement Website: www.pixelships.com
--- Ancient DOS Games Webshow: www.pixelships.com/adg

Reply 6 of 28, by robertmo

User metadata
Rank l33t++
Rank
l33t++

I think ddraw was not affected on your old systems cause nvidia's settings only affect opengl and direct3d. Anyway you can try ddraw too now. I think it still works just doesn't scale up. check overlay too. and direct3d from ykhwong's build 😉

Reply 7 of 28, by Gemini000

User metadata
Rank l33t
Rank
l33t

Well, DirectDraw mode fails to work properly on Windows 8 due to all kinds of depreciation. :P

One of the drawbacks to going with newer stuff for my new computer. For the most part, Windows 8 hasn't been TOO bad, certainly better than my Windows 7 experiences. (Yeah, I must be one of the few people on the planet who's had more trouble with Windows 7 than with Vista.)

If my programming skills weren't limited almost strictly to game development using third-party wrappers I'd be considering taking up the challenge of building a DirectDraw -> Direct3D/OpenGL system... though I have noted that attempting to run pre-DX9 or DirectDraw stuff on Windows 8 routes it through an emulation layer present in DirectX 11. One has to wonder why they just don't make a few minor changes to make that emulation layer decent enough to game with. :P

--- Kris Asick (Gemini)
--- Pixelmusement Website: www.pixelships.com
--- Ancient DOS Games Webshow: www.pixelships.com/adg

Reply 8 of 28, by robertmo

User metadata
Rank l33t++
Rank
l33t++

Can you remove the 'solved' mark from thread title as i still wonder about this:

Gemini000 wrote:

BTW: Anyone have any ideas why vertical retrace syncing might be doing this, even with DOS games that run the same framerate as my monitor and why it only affects games running with the "max" cycles setting?

BTW what about outputs: overlay and direct3d

Reply 9 of 28, by Gemini000

User metadata
Rank l33t
Rank
l33t

You just really wanna keep me from going off to have dinner, don't you? :P

Overlay mode doesn't seem to work any different from Surface mode for me... though Mech 2 did crash at one point while testing it, again with a Divide Overflow error. Maybe that problem has nothing to do with the vsync issues?

Direct3D I dunno because I don't have a build on-hand that supports it and I'm too hungry at the moment to care to go searching for one. I'll check that later. I'll also check later to see if any of the other random crashes I had are seemingly resolved from keeping vsync off.

--- Kris Asick (Gemini)
--- Pixelmusement Website: www.pixelships.com
--- Ancient DOS Games Webshow: www.pixelships.com/adg

Reply 10 of 28, by Gemini000

User metadata
Rank l33t
Rank
l33t

Just checked out DOSBox SVN Daum 5.6.2013 and have the following to report:

* In Direct3D mode, with vsync active, there are no issues.
* OpenGL and OpenGL_NB modes both have the same problems with vSync as in DOSBox 0.74.
* OpenGL_HQ mode however DOES NOT have these problems with vSync on... :O

--- Kris Asick (Gemini)
--- Pixelmusement Website: www.pixelships.com
--- Ancient DOS Games Webshow: www.pixelships.com/adg

Reply 13 of 28, by Shagittarius

User metadata
Rank Oldbie
Rank
Oldbie

I was just curious I run Windows 8 64bit on my Dosbox machine and use Ddraw and I haven't noticed any issues with it. What is it that you are seeing that makes you think theres a compat problem? I'm curious if I'm missing something or if perhaps there's a config problem somewhere on your end. I know that When I first got windows 8 I had permission problems on the first install that I didnt get on subsequent installs. Not saying that its a permission problem in your case just that I'm mystified as to how I can get different results from the same install and perhaps a reinstall might fix whatever the issue is your having with ddraw as well.

Reply 16 of 28, by h-a-l-9000

User metadata
Rank DOSBox Author
Rank
DOSBox Author

v-sync is blocking the emulator fully for up to one frame as emulated and real frame don't match exactly. The duration of the block varies however due to the beat effect. Could be that autocycle guessing responds in that way. Another thing causing mess is adaptive CPU frequency on the host, if you have it.

cycles=max is risky with nowadays CPUs. You will find games that weren't made for really fast computers. Also, under certain circumstances it can drop so low that i.e. interrupts can't be processed quickly enough in the guest code causing glitches or aborts.

1+1=10

Reply 17 of 28, by Gemini000

User metadata
Rank l33t
Rank
l33t
Shagittarius wrote:

I was just curious I run Windows 8 64bit on my Dosbox machine and use Ddraw and I haven't noticed any issues with it. What is it that you are seeing that makes you think theres a compat problem?

Actually, so long as I run windowed modes only and keep games running at their original resolutions, there are no issues.

If I go full-screen however, or attempt to scale to larger resolutions, THAT'S when the problems start...

Firstly, every screen-mode change in-game, including the switch into fullscreen and the switch out of fullscreen, generates a brief pause for about two seconds. This pause normally passes without issue but can greatly slow down the handling of games which have frequent mode changes for whatever reason, Mechwarrior 2 being a good example yet again since it changes modes TWICE every time you swap from the main interface to the gameplay itself or back again. This pause can also crash DOSBox, though typically only when switching from fullscreen to windowed or back again.

Secondly, if any scaling is performed, no filtering occurs, so all the pixels get aliased, even when using scalers.

--- Kris Asick (Gemini)
--- Pixelmusement Website: www.pixelships.com
--- Ancient DOS Games Webshow: www.pixelships.com/adg

Reply 19 of 28, by Shagittarius

User metadata
Rank Oldbie
Rank
Oldbie

Dunno if you have tried this but I set aspect=false, if I have it set to true I get slowdown. It doesn't seem to effect the way anything looks setting it to false, maybe it just depends on what your monitor does to it on its own? This is usually my combination for ddraw, but it won't do anything to help resolution changes.

I never even knew that wasn't normal until you pointed it out and I tried opengl to compare, it's a shame opengl is so blurry.