In the next version you can use the cycles-up/cycles-down keys to
reduce processor load when cycles=max.

Pan,

I'm not a developer (at least not a DOSbox developer) but I think it's a good idea for e.g. companies bundling DOSbox with a re-release of their old games. They wouldn't want people to have to mess with dosbox.conf.

It's in the same spirit as the cycles=auto and core=auto things: don't force the users to do work that the computer can do just as well, unless they themselves want to do more fine-tuning.

Another nice thing to have would be output=auto (and scaler=auto), but I guess that's a bit harder to pull off.

scaler=auto and output=auto are useless. scaler is a matter of personal preference, nothing else, and output is highly system-dependent in a way that might produce crashes or seem to work (but doesn't actually work) if the wrong values are selected.

With "scaler=auto" I simply meant "use either none or normal2x, depending on whether the selected output does hardware scaling". E.g. if emulated resolution is 320x200 and window size is 640x400, then with openglnb use none, with surface use normal2x

that is allready done.

Ok, guess I should read the code before starting to type...

In the next version you can use the cycles-up/cycles-down keys to reduce processor load when cycles=max.

This would be a help. But it does mean that the user would have to adjust it manually themselves; on every execution of the program. The idea I suggested would allow a limit to be set via variable in the configuration file or emulated console and it could therefore also be stored or invoked via batch file.

I'm not a developer (at least not a DOSbox developer) but I think it's a good idea for e.g. companies bundling DOSbox with a re-release of their old games. They wouldn't want people to have to mess with dosbox.conf.

True, it would be useful for them too.

The cycles=max idea is great for pre-creating configuration files, but it seems wasteful when most cycles being generated are not needed 😀

But if you want to specify a hard upper limit for cycles=max, why not
using fixed cycles??

But if you want to specify a hard upper limit for cycles=max, why not using fixed cycles??

As I said at the start, it seems pointless initially 😀

But consider this... you have a game that you want to create a pre-configuration for. It works between 3000 and 10000 cycles with varying degrees of performance. Under the current system, you can either allow the game to run at the minimum level required by setting cycles=3000, or try and make best use of faster PC's with cycles=10000.

The former would work fine, but it would heavily penalize faster PC's by forcing them to work at the lowest level. The latter is disastrous for slower PC's, they would simply max out on CPU activity (at 100% constantly) and the game would likely suffer serious performance and sound problems.

Neither solution is very practical. The cycles=max is therefore the only reasonable option. I should add that setting cycles=100000 and cycles=max is not the same thing as you can quickly determine by trying it 😀

My main thoughts on this though is that the cycles=max option is wasteful for this task on faster PC's. Setting a simple limit on the max option would remove this waste. Something like a 'maxcycles' variable similar to 'cycles' would be great.

If this was implemented, then Dosbox could make all use of a CPU up to 10,000 cycles where it would go no further. If a slower PC was used, the engine would scale to whatever it was capable of using. Therefore, setting a true automatic scaling system for a particular game would be possible.

cycles=max is definitely different from cycles=xyz simply because it
varies the cycle count on demand. And the max setting is not really
wasteful because most newer games will just run smoother. If you
are concerned about keen&co not needing this, have a look at cycles=auto.

cycles=max is definitely different from cycles=xyz simply because it varies the cycle count on demand.

Yes. I'm not a Dosbox newbie you know 😉

And the max setting is not really wasteful because most newer games will just run smoother

Quite likely, yes. Not at all relevant to this discussion however 😀 I was previously talking about cycle limits, so I obviously wasn't thinking in terms of new games. If I was, it would of been perfectly reasonable to set cycles=max and then I wouldn't of needed to post 😀

There are some older games anyway that simply don't run well with max enabled, although they still require a fair amount of cycles or so for good performance. In this case, max is definitely not a good thing.

If you are concerned about keen&co not needing this, have a look at cycles=auto.

I didn't know much about cycles=auto before, but now I realize it's the default mode in Dosbox and merely sets the cycles to max when the program thinks it might be needed. Unfortunately, it isn't remotely useful in this case.

The problem with cycles=auto is that the logic it uses (or used a while ago, I didn't recheck the newest CVS code) was simply: "If CPU is in real mode, do cycles=3000; if in protected mode, do cycles=max." While surprisingly effective for most titles, for some games that's simply too crude. E.g. Ultima 7 will run too fast with max on most systems even though it's a protected mode game; and it seems that a few PM games don't seem to switch to PM until after a real-mode intro, which will thus run much too slow. A suspected example would be Descent, which doesn't seem to work well with cycles=auto until you actually start flying.

Clearly the max routine is flawed. Take the example of Death Gate (a protected mode game). In max mode, the game runs around 16500 cycles with a lot of audio drops during the PCM dialogues. But if you use a fixed cycle of 16500, the game works without a hitch. Go figure.

Limiting cycles is useful when you don't want the game to use more than xx cycles and xx would be too high for some scenes and max would be too high for other 😀 I don't know if limiting processor usage has the same effect...

> for some games that's simply too crude

Feel free to come up with something much better.

> Clearly the max routine is flawed.

Don't use it then.

wd wrote:

> for some games that's simply too crude

Feel free to come up with something much better.

Hello wd,

firstly let me assure you that no offense was intended at all. DOSBox is an amazing Program that I couldn't have dreamed of cooking up myself.

Secondly, I'll look into it this weekend, at least a small cycles=max<n> patch shouldn't be too difficult I hope.

Best wishes,

If that is needed there's no problem to add it. But i don't see
the ultimate reason for this at the moment. Reducing could
work by a hard upper cycles limit (not that useful imo) or by
having a percentage modifier (like what the cycles up/down
keys do at the moment for cycles=max).

The problem with cycles=auto is that the logic it uses (or used a while ago, I didn't recheck the newest CVS code) was simply: "If CPU is in real mode, do cycles=3000; if in protected mode, do cycles=max." While surprisingly effective for most titles, for some games that's simply too crude.

Yes, I've noticed that problem. Sometimes also the max setting is used when I don't think it's really necessary. I often wanted to disable it, but thought it was part of the main Dosbox code and couldn't be changed 😀

I didn't realise that this was an offset of the cycles=auto setting. In fact, I'd never heard of that setting before this thread. Now that I do know, I can set cycles back to 3000 😀

Clearly the max routine is flawed. Take the example of Death Gate (a protected mode game). In max mode, the game runs around 16500 cycles with a lot of audio drops during the PCM dialogues. But if you use a fixed cycle of 16500, the game works without a hitch. Go figure.

I've noticed some sound problems using max mode, but I didn't realise that Dosbox may be the cause, I thought my PC was just too slow. I'll have to try a fixed setting and see.

> for some games that's simply too crude […]
Show full quote

> for some games that's simply too crude

Feel free to come up with something much better.

> Clearly the max routine is flawed.

Don't use it then.

I don't think that was really fair wd. Kaminari and TeaRex were only demonstrating their personal experiences with Dosbox. Nothing wrong with that.

Reducing could work by a hard upper cycles limit (not that useful imo) or by having a percentage modifier (like what the cycles up/down keys do at the moment for cycles=max).

I think having a hard upper cycles limit is the best solution to this issue. The latter solution is not at all helpful.

I already gave a set of problems in which this patch could be useful, so I'm not sure how you think it's not helpful 😀

> I don't think that was really fair wd. Kaminari and TeaRex were only
> demonstrating their personal experiences with Dosbox. Nothing wrong
> with that.

And what's the unfair part??

> I think having a hard upper cycles limit is the best solution to this issue.

Better use a frontend with some default templates. Adding a config option
for upper cycles limits just to avoid your new pc not wasting cpu time is
not a highly needed thing.