jvieira wrote:

EDIT: In playing with it, its still not great performance, but it is playable, and it no longer locks up. I do still hope that one day a solution can be found to the above issues, but in the mean time, this will suffice.

What are your settings for things like core, cycles, and output?

MiniMax wrote:

jvieira wrote:

EDIT: In playing with it, its still not great performance, but it is playable, and it no longer locks up. I do still hope that one day a solution can be found to the above issues, but in the mean time, this will suffice.

What are your settings for things like core, cycles, and output?

Well let's see. I've been changing things about alot, but here are some of my settings from current dosbox.conf which I think may be relevant:

fullscreen=true
fulldouble=false (is double buffering slower?)
fullresolution=original (not sure if there is a better setting here)
output=surface
frameskip=2
scaler=none (was on normal2x, not seeing alot of difference)
core=normal (tried dynamic briefly, it didn't seem alot faster)
cycles=12000

If there is something of interest I have missed here, let me know, I'll mention what it's set too.

I am not certain on the best cycles setting yet.. I played around in the game about an hour so far, and I found that it would flucuate. Maybe it's just my perception. I just couldn't seem to lock down one number that worked all around. I'd constantly fiddle with it. I'd say I have moved the cycles between 9000-15000 range, up and down, trying to experiement (and looking at CPU usage).

Oh and I also tried dos32a extension, by changing the four main game .exe's to use it. But then I started getting a problem with the mouse stopping responding, and read another post on these boards saying that switching back to DOS4GW fixed it for them (and it did me as well).

Still, this is a mile and and half away from where I was before I changed the CD rom mount command. It's not that bad, I probably made it sound worse that it is in my last response.. It definately could be snappier and better. I wish it was just a bit more... But it's working good enough to play, that is for sure.

core=auto
cycles=auto
game should run fine then. (be sure to set the soundcard to sb pro with the right irq)

auto eh? I'll give that a try in a little while, thanks for the tip. Wow, words from the author himself. Cheers and thanks.

Oh, and I have it on SB16, IRQ7, DMA5.. Will SB Pro IRQ7 DMA1 give better performance?

sb16 seems to cause slow videos with cycles=auto in xcom Apoc (I recently came to that conclusion. They seem to time things differently then).

EDIT: easier to just update this last post with the final results.

I ended up getting it to run very well now. I'm quite pleased.

In the end I had to turn the core=auto to core=normal again to achieve this. But with cycles=auto, the gameplay is smooth and stable. When I had them both on auto, it was still kind of choppy and stuttery, regardless of the sound configuration.

I also switched down to SBPro IRQ7 DMA1 in the end, to be safe and get the best performance.

It really works great now. I'm very pleased.

Thanks alot for your help!

Hi -

I am attempting to help a friend troubleshoot the exact same problem you began this thread with, jvieira - corrupted graphics under VDMSound with an ATI graphics card. I've helped them set up dosbox and pretty much matched the steps and suggestions as shown here (and duplicated the setup on my own system), but we're both seeing significant slowdown during more 'active' gameplay; i.e. when large numbers of cityscape buildings collapse and there's a bunch of particles for a moment, or during very active real-time tactical firefights. We've verified the problem by seeing how localized it is; in the tactical example, if we move the active screen away from the fight, everything smooths out again. We've had some limited success manually entering numeric values for cycles and increasing/decreasing with key commands, but it's still annoyingly choppy in some areas.

The contrast to this is that VDMSound's cpu emulation exhibits none of this slowdown for either of us, but for me it produces scratchy music/sound and for my friend it produces the aforementioned graphics corruption. The only clue I have as to what's going on with their system is that when they alt-tab out of xcom under VDMSound and then attempt to restore it, their monitor displays "signal out of range" and remains black. I personally experience no problems switching focus like that.

My friend's system has a p4 processor running at 3.4 ghz and an ATI 1300 pro graphics card, if that helps in identifying the graphics issue.

If anyone has pointers as to how we can either smooth out Dosbox further or fix the graphics corruption issue under VDMSound, I would very much appreciate the input. Tips on how to remove VDMSound scratchiness would be appreciated too 😀

-Auryn

VDMSound's cpu emulation

Which is nonpresent, jfi.

Try something like "cycles=max 95%" in dosbox.conf and play with the
percentage value a bit.

VDMSound's cpu emulation

Which is nonpresent, jfi.

Ah, I see; in any case, it still runs smoother than dosbox for me at the moment. Wish I knew why!

Try something like "cycles=max 95%" in dosbox.conf and play with the
percentage value a bit.

We had set it to flat cycles=max before, and there was still slowdown as mentioned above. I tested this as-written and still experienced significant slowdown during 'busy' action scenes.

On a side note, I played around with VDMSound's settings some more and removed 99% of the scratchiness, so that issue is gone; xcom and/or something else liked the SBPro/7/1 setting better than the SB16/7/1 setting for some reason.

-Auryn

I hope one day someone figures out what causes this graphics / palette problem with some newer cards. I expect it will continue to be an issue into the future when playing other older games..someone else in this thread had already reported a similar problem in a different game.

I have been playing XCOMA since I last posted, and I have the same problems that Auryn describes, like some big slow downs during battles. It's less than perfect, but it's been acceptable. But it would certainly be preferable to play it with just VDMSound, it runs fantastic like that. So hopefully this weird backwards compatability issue will get figured out by some brilliant coder one day 😉

It won't be a problem in the future because DOS games will not work in Windows in the future (32bit Vista with Vista drivers will not allow DOS games that use video modes other than text to run in fullscreen) so you'll need to use a program like GliDOS or an emulator (or install the XP drivers in Vista).. 64bit Vista does not support DOS games so you'll need to use an emulator.

So your options are:

Contact ATI and report your problem. (Good luck....)
Support people like the author of GliDOS or dvwjr who still support NTVDM.
Use emulators like DosBox.
Use an old machine if you don't like emulators (or a video card that doesn't have the problem).
Learn how to fix the problem yourself....

One item of note where our cases differ, Jvieira - when my friend tried running xcom with no sound, the palette issue stayed; you'd previously posted that disabling sound fixed the graphics issue but left you with no sound. This is one of those cases where its a little harder for me to troubleshoot the problem since its not on my system right in front of me... sigh.

My searching yielded one possible solution that we're hesitant to test/implement; a driver called giveio.sys, which supposedly disables some of XP's limitations on programs directly accessing hardware registers such that older video modes would work better/at all. When I try to research giveio.sys, however, it seems to be more commonly used for serial ports and the like. Some posts even suggested it was almost exclusively malware. Does anyone know more about this driver and/or whether it could work for this problem?

Someone also mentioned that there might be a patch for the ATI BIOS to allow it to handle additional (VESA) video modes, but didnt have any specific suggestions or places for me to download such a fix; anyone know if this is a viable option or if it makes no sense?

-Auryn

I have used that giveio.sys with some game under WinXP - don't remember which one any more.

giveio is just like porttalk. It allows access to IO ports that NT doesn't allow. This is dangerous since your talking directly to the hardware so the chances of crashing your machine or making it unstable are greater.

DosFreak wrote:

It won't be a problem in the future because DOS games will not work in Windows in the future (32bit Vista with Vista drivers will not allow DOS games that use video modes other than text to run in fullscreen) so you'll need to use a program like GliDOS or an emulator (or install the XP drivers in Vista).. 64bit Vista does not support DOS games so you'll need to use an emulator.

Ahh, I see, I hadn't realized that things would change so much with Vista. I just figured this would be likely with some other games in the more near future though, like the guy with the similar Jedi Knight problem earlier in the thread. I guess it's unfortunate that ATI chose to change whatever they changed. I wouldn't know where to start solving it myself. But thanks for the information.

Auryn wrote:

One item of note where our cases differ, Jvieira - when my friend tried running xcom with no sound, the palette issue stayed; you'd previously posted that disabling sound fixed the graphics issue but left you with no sound.

No I'm sorry if I gave the wrong impression, that is not what happened. When talking about the disabling sound fixing anything, it was fixing my problems getting the game working in DOSBOX, not running in XP w/VDMSound.

When I first tried to play it in DOSBOX, it would lockup constantly. It was suggested I try without sound, and that fixed the lockups. When re-enabling sound, I noticed a correlation between the stuttery-ness of the game, and the disc reading action from the CD.. This lead me to think it was related to the CD possibly, and in the end I found by mounting the drive differently the lockups and stuttery-ness went away, and it became fully playable in DOSBOX (apart from the slowdowns in big battles which you mention, but it's not been awful or anything).

But that was all in DOSBOX. Nothing I have ever done has fixed the palette corruption when running the game in XP w/VDMSound.

DosFreak wrote:

giveio is just like porttalk. It allows access to IO ports that NT doesn't allow. This is dangerous since your talking directly to the hardware so the chances of crashing your machine or making it unstable are greater.

So in other words, probably not a good idea to try it. That's what we were trying to determine; thanks for the info.

jvieira wrote:

No I'm sorry if I gave the wrong impression, that is not what happened. When talking about the disabling sound fixing anything, it was fixing my problems getting the game working in DOSBOX, not running in XP w/VDMSound.

Ah, that makes a lot more sense; I'm kinda glad to get this cleared up, since it re-confirms that we're looking at the same issue with no differences (I showed my friend the screenshot you posted; they said their screen looks the exact same).

@ DosFreak and/or whomever else wishes to respond: was there any merit to the 'ATI BIOS patch for VESA' comment I mentioned in my previous post, or is that another dead end? I cant seem to find anything to that effect on ATI's site or elsewhere.

-Auryn