Still cool 😀

Dominus wrote:

he he
(though I do have to warn that this is asking for trouble especially in SI since it could set some flags that shouldn't be set)

Of course, it's not even really playable at that resolution anyway without some way to scale text and the menus. Way too hard on the eyes. Not to mention if you tried to locate that MoonOrb in your backpack once you start collecting junk. The horror.....

I once played through Black Gate and Serpent Isle in 800x600 though with scale2x and it worked pretty nice. Didn't seem to set off anything too bad, although I do recall some odd moments such as the banquet hall in Monitor acting up.

yeah, mostly higher resolutions are ok, the problem is mostly that when you "take" something from too far away a flag might not be set that is triggered by a proximity egg (sorry if that gets to technical). In the original you couldn't be that far away from the egg for that to occur (probably only if you knew exactly where to go and grab something by just a visible pixel). Because we had people having problems with this it has become a knee jerk reaction for me to warn against too high resolutions 😀

@Speon, if you are wondering what we are talking about, check out http://exult.sf.net
I'm the documentation slave for that project 😀

Dominus wrote:

@Speon, if you are wondering what we are talking about, check out http://exult.sf.net
I'm the documentation slave for that project 😀

Oh thanks, I'm well familliar with Exult. 😀 I love the work you all have done over the years (I'm particularly excited about the Pocket PC port).

That said, when it comes to playing the game, I'm a bit of a purist and enjoy DOSBox's approach.

Dominus wrote:

"losing the source" was just one of their excuses, they didn't look too hard or they would have found it on one of their old employees.

Hmm...this sounds like you might know who has the source code. Tseramed perhaps? 😁 I was under the impression it was lost post-SI and pre-U8, before EA completely stepped in.

Todd Demarest prolly has less of the source than Garriott supposedly kept.

I had this problem when I switched output from ddraw to openglnb ... now that I switched it back to ddraw, the audio stopped stuttering. Only problem is in windowed mode, ddraw is sort of blurry. Sucks.

Datus wrote:

I had this problem when I switched output from ddraw to openglnb ... now that I switched it back to ddraw, the audio stopped stuttering. Only problem is in windowed mode, ddraw is sort of blurry. Sucks.

Wow - this fixed the issue! I had my output set to surface (no problems in the past up to this point) and switching to opengl or openglnb resolved the skipping issue. For the record, overlay and ddraw modes cause the audio to skip as well.

I did upgrade my video card recently, so perhaps this is some kind of strange side effect with 0.72. It's odd that it only seems to affect a small component of this particular game, however.

Anyways, thanks all for the help and insight.

Also if your resolution seems kind of blurry , try reading this post - Feature request: Double sized window.

Everything is working great for me now...

It usually takes a beefier game that needed a fast 386 or 486 back in the day to make the difference in performance between output methods a significant factor in DOSBox. The general pattern is that ATi has better performance with overlay and ddraw, while nVidia has better performance with the opengl methods. This pattern seems fairly clear; such that I wonder if it would be worth mentioning more prominently in DOSBox's conf file (comments) and README...

Actually considering how little amount of power DOSBox uses such a factor (ATI vs Nvidia) would not make the slightest difference.

No difference? Note that speon's issue was solved by switching to opengl output methods in combination with using an nVidia card; and nVidia has long been the opengl performance champ. I'd say it clearly does make a difference.

The man has an E6600 and an 8600, theres no excuse for such results. I've used DDraw on every one of my nvidia cards dating back to an Nvidia Geforce MX4000....and if that card can do it then any can.

Honestly the speed difference between OpenGL and DirectX/3D has been proven to be negligible, especially with modern cards like the 8600-8800. I mean 9 games out of 10 all use Direct3D, Nvidia doesn't shoot themselves in the foot by supporting the rarely used OpenGL.

I think this a matter of his configuration here. There must be another factor, because clearly his hardware is capable.

Maybe some wait for vret, could check the display property tools.

wd wrote:

Maybe some wait for vret, could check the display property tools.

Could be. I imagine it's something along the lines of a forced option in the Nvidia control panel....especially if just 0.72 is causing it.