What kind of glitches? I don't have graphical issues with my Geforce 4 Ti 4600 using windows 98se and NOLFBLIM (updated NOLFB) - Enables VSYNC for DOS Games

In the dos section of the forum there are some vesa fixes listed, could give those a shot.

Hello friend, thanks for your answer I'll give it a read later.
Also, someone move this topic to Marvin I made a mistake and created it here 😜

moved. 😉

Your problems sound like they could be perhaps related to motherboard chipset too. Features like USWC can play havoc with DOS graphics. I've seen this with Voodoo3 as well.

No such option. I'm using an ASUS CUSL2 with a Pentium III at 1GHz. Nevermind the screen tearing, it's probably caused by the lack of Vsync like RogueTrip noted.
The biggest problem is that some games refuse to use SVGA, because they can't find the card. These include X-Men Children of the Atom and Carmageddon. I've tried using the latest version of UniVBE, VBEplus and FreeBE/AF.

The latest version of UniVBE doesn't support Geforce cards (See here for a list of supported chips).

IMO the easiest way out of this is installing a S3 Trio/Virge. 😉

The ATI equivelant isn't much better either. 800x600 max supported by VESA. Some chipsets outright don't support 640x480 but support the other lower/higher vesa modes (WTF!?)

I should try the Kyro II again since I never really assessed its VESA capabilities fully.

Yeah the solution is to stick with mid '90s S3 cards for your DOS gaming.

Sometimes it might be useful to grab one of these essentially infinitely fast VESA cards though for SVGA games... If you have a really fast CPU behind it, like a Coppermine or Tbird.

Oh well, I'll install a Voodoo 3 PCI as a secondary card in a couple of weeks so that should take care of the problem. I'll have to make the Voodoo 3 the primary card by selecting "Initialize PCI Card" on the Bios first right? Will there be any conflicts between the GF4 AGP and the Voodoo 3 PCI?
But it's kinda weird. My GeForce 2 Ti worked fine a few months ago I think, but I really want the GF4 for there for newer games.

Something else that comes to mind but I don't want to create a new thread about it:
Is there any Soundfont for the Live! cards that makes them sound like the AWE32/64?
And is there any way to use an external midi synth in Windows 98 through the classic MIDI to USB cable? My system couldn't find the necessary drivers to recognize it.

Thank you for all your answers, I'm trying to build the Ultimate All_in_One Retro System and your answers have helped a great deal 😁

F2bnp wrote:

Is there any Soundfont for the Live! cards that makes them sound like the AWE32/64?

1MGM.SF2

Thanks leileilol 😁

Now to get my SC-7 working in Win98...
Any help with this one?

leileilol wrote:

1MGM.SF2

I hope that truly captures the squealing-rodent aural joy of the AWE32. Although curiously sometimes the AWE32 reminds me of a SNES's "wavetable".

well, it's the closest you can get to emu8k with a emu10k1.

A SPC700 wavetable would need a very buffery echo reverb, and mandatory 4-bit compression on samples

Running it on a Vortex 2 now, it sounds pretty close, although there are some hiccups here and there.
Swaaye I love you man, you made me laugh so hard! It is true, the AWE32's sound is widely disliked, but I love it, mainly because I was desperate for something other than FM Synth and a guy here in Greece gave me an AWE64 Gold absolutely free!

Now if I can get the SC-7 to run under Win9x I'll remove the Vortex 2 as I'll no longer need the Yamaha DB60XG. Using Win98SE and the Native Usb Drivers 3.3, I can get Windows to recognize the module as USB Audio Device, but it gave a blue screen and now ,on the Device Manager, the device is noted with a yellow mark. On opening it, you can read the following:

"Windows stopped responding while attempting to start this device, and therefore will never attempt to start this device again (Code 11.)

For more information, look up ASD in Windows Help.
Try upgrading the device drivers for this device."

It cracks me up with this whole "will never attempt again" business. It's as if the OS is calling you a moron for installing the device 😜

I know this is a very old thread, but I just wanted to add my experience with a Geforce4 Ti 4200 using Windows 98 SE and running Duke 3D (Atomic Edition).

For some reason I couldn't get the VESA modes/resolutions working with any of the suggested fixes, all I got was totally scrambled graphics or an intro that froze after a couple of seconds. But then I tried changing my monitor to a VGA one instead of the DVI model I was using and voilá it suddenly worked! Though I ended up going back to my initial monitor as it has both VGA and DVI and the VGA port on that one also works with the above.

I have no clue why it works, it just seems DVI is a no-go.

So for anyone coming from Google like me and searching for this I hope it will also help you.

Similar Experience here with a Geforce 4 4200 TI (from MSI). Tested Duke 3D on 640x480 and 800x600 and also Quake on 640x480. Both produce glitches: Every 2 minutes or so, they insert one frame which is scrambled graphics as seen on screenshot (screenshot made from a video recording to get the exact frame).
Same occurs if you use the DVI Port but with Analogue instead. If you use the VGA port instead, there are no issues.
Haven't tested (and wont be able to test in next weeks) if same issues also occur in Windows or vanishes at a certain resolution. I used that card originally back at release in a then-modern pc on windows and didnt have any issues, so there needs to be one factor / threshold.

try NOLFB, it might be able to fix this at a performance cost. even some older cards can have this problem. lately, i haven't actually noticed this issue on a voodoo3, which also doesn't have the "snow" issue with screen tint effects (damage, health pickups etc.) that happens with nvidia.

if i recall correctly, one of the quake help file mentions some possible issues when doing page flipping without vsync, and thought this is how that actually looks in practice. but there being a DVI/VGA difference is new to me though.

auron wrote on 2023-04-16, 17:45:

try NOLFB, it might be able to fix this at a performance cost. even some older cards can have this problem. lately, i haven't actually noticed this issue on a voodoo3, which also doesn't have the "snow" issue with screen tint effects (damage, health pickups etc.) that happens with nvidia.

if i recall correctly, one of the quake help file mentions some possible issues when doing page flipping without vsync, and thought this is how that actually looks in practice. but there being a DVI/VGA difference is new to me though.

Thank you. Tested, not sure whether it's worth it.
It does remove the glitch. But it lowers the FPS from around 45 down to 27, and it introduces massive sync issues. You can basically see this horizontal break wandering from top to bottom during the course of maybe 60 seconds. (screen made while turning left and right)

yes, with the fallback banked VESA mode page flipping gets disabled and unlike quake there are no options to change this, so at 27 FPS the tearing is going to be pretty bad. if you run this on a very fast machine the FPS might get high enough to a point where the tearing wouldn't be very noticeable. then there's also NOLFBLIM which forces vsync, but i forgot if this is double or triple buffered. if it's double buffered, such as what ati cards are forcing, you'd likewise better be running a fast system at sufficiently low res to hit that 60 mark, or else it's going to be dropping to 30 or 15 all the time. vsync also comes with added input lag of course.

if high FPS in high resolutions are the goal, i'd really look towards source ports instead of the original code. even according to silverman himself some of the drawing routines in build are inefficient on 6th gen processors, and in my own testing a p200mmx outperformed a pii 233 in duke3d, which is pretty ridiculous.

Closed. Old thread is old
Open your own thread for your own isssue.
Also:
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)
https://falcosoft.hu/dos_softwares.html#mskvbef7